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The present invention relates to the field of electronic commerce (e-commerce) and par- 
ticularly to electronic systems in capital markets and other e-commerce applications with high 
availability and scalability requirements. 

Historically, mission critical applications have been written for and deployed on large 
mainframes, typically v^th built-in (hardware) or low-level operating system (software) fault- 
tolerance. In some prior art, such fault-tolerance mechanisms include schemes where multiple 
central processing units (CPUs) redundantly compute each operation and the results are used 
using a vote (in the case of three-way or more redundancy) or other logical comparisons of the 
redundant outcomes in order to detect and avoid failures. In some cases a fault-stop behavior is 

Attorney Docket No.: ATAE1015DEL Express Mail Label No.:EL328296286US 

ioi5_oo^7^20.fi.wpd Page 1 of 94 7/20/0-22:31 



COPYRIGHT NOTICE 



BACKGROUND OF THE INVENTION 





implemented where it is preferred to stop and not execute a program operation when an error or 
other undesired condition will result. This fault-stop operation helps to minimize the propaga- 
tion of errors to other parts of the system. In other implementations, elaborate fault recovery 
mechanisms are implemented. These mechanisms typically only recover hardware failures since 
application failures tend to be specific to the particular application software. To detect errors in 
application software, vast amounts of error-handling code have been required. Certain financial 
applications have devoted as much as 90% to error detection and correction. Because of the 
enormous complexity of such software applications, it is nearly impossible to entirely eliminate 
failures that prevent the attairmient of reliable and continuous operation. 

Increasingly, systems need to be available on a continuous basis, 24 hours per day, 7 days 
per week (24/7 operation). In such nonstop environments it is undesirable for a system to be un- 
available when system components are being replaced or software and hardware failures are de- 
tected. In addition, today's applications must scale to increasing user demands that in many 
cases exceed the processing capabilities of a single computer, regardless of size from small to 
mainframe. When the system load cannot be handled on a single machine, it has been difficult 
and costly to obtain a larger machine and move the application to the larger machine without 
downtime. Attempts to distribute work over two or more self-contained machines is often diffi- 
cult because the software typically has not been written to support distributed computations. 

For these reasons, the need for computational clusters has increased. In computational 
clusters, multiple self-contained nodes are used to collaboratively run applications. Such appli- 
cations are specifically written to run on clusters from the outset and once written for clusters, 
applications can run on any configuration of clustered machines from low-end machines to high- 
end machines and any combination thereof When demand increases, the demand is easily satis- 
fied by adding more nodes. The newly added nodes can utilize the latest generation of hardware 
and operating systems without requiring the elimination or upgrading of older nodes. In other 
words, clusters tend to scale up seamlessly while riding the technology curve represented in new 
hardware and operating systems. Availability of the overall system is enhanced when cluster 
applications are written so as not to depend on any single resource in the cluster. As resources 
are added to or removed from a cluster, applications are dynamically rescheduled to redistribute 
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the workload. Even in the case where a significant portion of the cluster is down for service, the 
application can continue to run on the remaining portion of the cluster. This continued operation 
has significant advantages particularly when employed to implement a cluster-based component 
architecture of the type described in the above-identified cross-referenced application entitled 
MARKET ENGINES HAVING EXTENDABLE COMPONENT ARCHITECTURE. 

While clustering technology shows promise at overcoming problems of existing systems, 
there exists a need for practical clustering systems. In practical clustering systems, it is undesir- 
able for each application in a cluster system to manage its own resources. First, it is inefficient 
to have each application solve the same resource management problems. Second, scheduling for 
conflict resolution and load-balancing (which is important for scalability) is more effectively 
solved by a common flexible (extensible) resource manager that solves the common problem 
once, instead of solving the problem specifically for each application. Furthermore, failure 
states tend to be complex when each application behaves differently as a result of failures and 
vsdth such differences, it is almost impossible to model the impact of such failures fi-om applica- 
tion to application running on the cluster. To overcome these problems, conmiercial and aca- 
demic projects have arisen with the objective of providing a clustering architecture that provides 
isolation between physical systems and the applications they execute. 

To date, however, proposed clustering architectures are complex and can only handle a 
limited number of specific system failures. In addition, proposed clustering software does not 
appropriately scale up across multiple sites. There is a need, therefore, for a simple and elegant 
clustering architecture that includes fault-tolerance and load-balancing, that is extendable over 
many computer systems and that has a flexible interface for applications. In such an architec- 
ture, the number of failure states needs to be kept low so that extensive testing is possible to ren- 
der the system more predictability. Hardware as well as software failures need to be detected 
and resources need to be rescheduled automatically, both locally as well as remotely. Resched- 
uling needs to occur when a particular application or resource is in high demand. However, re- 
scheduling should be avoided when unnecessary because rescheduling can degrade application 
performance. When possible, rescheduling should only occur in response to resource shortages 
or to avoid near-term anticipated shortages. If the system determines that resource requirements 
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are likely to soon exceed the capacity of a system element, then the software might appropriately 
reschedule to avoid a sudden near-term crunch. The result of this "anticipatory" rescheduling is 
avoidance of resource bottlenecks and thereby improvement in overall application performance. 
The addition and removal of components and resources needs to occur seamlessly in the system. 

In view of the above background, it's an object of the present invention to provide an 
improved fault-tolerance framework for an extendable computer architecture. 

Summary 

The present invention is computer system having a fault-tolerance framework in an ex- 
tendable computer architecture. The computer system is formed of clusters of nodes where each 
node includes computer hardware and operating system software for executing jobs that imple- 
ment the services provided by the computer system. Jobs are distributed across the nodes under 
control of a hierarchical resource management unit. The resource management unit includes hi- 
erarchical monitors that monitor and control the allocation of resources. 

In the resource management unit, a first monitor, at a first level, monitors and allocates 
elements below the first level. A second monitor, at a second level, monitors and allocates ele- 
ments at the first level. The framework is extendable from the hierarchy of the first and second 
levels to higher levels where monitors at higher levels each monitor lower-level elements in a 
hierarchical tree. If a failure occurs down the hierarchy, a higher level monitor restarts an ele- 
ment at a lower level. If a failure occurs up the hierarchy, a lower-level monitor restarts an ele- 
ment at a higher level. While it may be adequate to have two levels of monitors to keep the 
framework self-sufficient and self-repairing, more levels may be efficient without adding signifi- 
cant complexity. It is possible to have multiple levels of this hierarchy implemented in a single 
process. 

In some embodiments, each of the monitors includes termination code that causes an ele- 
ment to terminate if duplicate elements have been restarted for the same operation. The termina- 
tion code in one embodiment includes suicide code whereby an element will self-destruct when 
the element detects that it is an unnecessary duplicate element. 
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In one local level embodiment, the resource management unit includes agents as ele- 
ments in the first level where the agents monitor and control the allocation of jobs to nodes and 
includes a local coordinator in the second level where the local coordinator monitors and con- 
trols the allocation of jobs to agents. Also, the agents monitor the local coordinator. Failure of a 
5 job results in the monitoring agent for the failed job restarting a job to replace the failed job. 
Failure of an agent results in the monitoring agent for the failed agent restarting of an agent to 
replace the failed agent. Failure of the local coordinator results in restarting of a local coordina- 
tor to replace the failed local coordinator. In a particular example of a local level embodiment, 
the agents are implemented as host agents where a host agent only monitors the jobs running on 
10 one node. 

In a higher level hierarchy, one or more group coordinators are added at a group level 
above the local level where each group coordinator monitors and controls multiple local coordi- 
^if nators where each local coordinator monitors and controls lower level agents which in txim mon- 
ffi itor and control lower level jobs. 

'X5 In a still higher level hierarchy, one or more imiversal coordinators are added at a univer- 

sal level above the group level where each universal coordinator monitors and controls multiple 

5 local coordinators where each local coordinator monitors and controls lower level agents which 

in turn monitor and control lower level jobs. 

The present computer system gives highest priority to maintaining the non-stop operation 

£30 of important elements in the processing hierarchy which, in the present specification, is defined 

^'^ as operations that are jobs. While other resources such as the computer hardware, computer op- 
erating system software or communications links are important for any instantiation of a job that 
provide services, the failure of any particular computer hardware, operating system software, 
communications link or other element in the system is not important since upon such failure, the 

25 job is seamlessly restarted using another instantiation of the failing element. The quality of ser- 
vice of the computer system is represented by the ability to keep jobs running independently of 
what resource fails in the computer system by simply transferring a job that fails, appears to have 
failed or appears that failure is imminent and such transfer is made regardless of the cause and 
without necessarily diagnosing the cause of failure. 
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The present computer system utilizes redundancy of simple operations to overcome fail- 
ures of elements in the system. The redundancy is facilitated using hierarchical monitors that 
decouple fault-tolerance processes for monitoring failure from the services (executed by applica- 
tion programs that are implemented by jobs). 

An indication of progress of a service is determined by using, in applications that provide 
a service, the capability of processing progress messages. The progress messages traverse the 
vital paths of execution of the service before retuming a result to the progress monitor. The 
progress monitor is independent of the fault-tolerance layer and does not interfere with fault-tol- 
erant operation. Restart of failing jobs is simple and quick without need to analyze the cause of 
failure or measure progress of the service. 

The present computer system inherently provides a way to seamlessly migrate operation 
to new or different hardware and software. Because the present computer system inherently as- 
signs jobs among available resources and automatically transfers jobs when failures occur, the 
same dynamic transfer capability is used seamlessly, maintaining non-stop operation, for system 
upgrade, system maintenance or other operation where new or different hardware and software 
are to be employed. 

The present computer system operates such that if any element is in a state that is un- 
known (such as a partial, possible or imminent failure) then the fault-tolerant operation reacts by 
assuming a complete failure has occurred and thereby immediately forces the system into a 
known state. The computer system does not try to analyze the failure or correct the failure for 
purposes of recovery, but immediately retums to a known good state and recalculates anything 
that may have happened since the last known good state. 

The present computer system works well in foUow-the-sun operations. For example, the 
site of actual processing is moved from one location (for example, Europe) to another location 
(for example, US) where the primary site is Europe during primary European hours and the pri- 
mary site is US during primary US hours. Such foUow-the-sun tends to achieve better perfor- 
mance and lower latency. The decision of when to switch over from one site to another can be 
controlled by a customer or can be automated. 
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The present system includes an interface that collects and provides output information 
and receives input information and commands that allow humans to monitor and control the 
computer system and each of the components and parts thereof. The interface logs data and 
processes the logged data to form statistics including up-time, down-time, failure, performance, 
configuration, versions, through-put and other component and system information. The interface 
provides data for system availability measurements^ transaction tracking and other information 
that may be useful for satisfying obligations in service agreements with customers. 

The present system provides, when desired, customer process isolation. For example, 
first jobs rurming on first nodes associated with a first customer are isolated fi-om second jobs 
associated with a second customer running on second nodes, where the second nodes are differ- 
ent from the first nodes. 

The foregoing and other objects, features and advantages of the invention will be appar- 
ent from the following detailed description in conjunction with the drav^ngs. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 depicts computer system consisting of distributed groups of clusters. 

FIG. 2 depicts details of the clusters of the type employed in FIG. 1. 

FIG. 3 depicts further details of the processes running on the clusters of FIG. 2. 

FIG. 4 depicts a logical view of the local job manager hierarchy running at levels in the 
hierarchy above jobs running on nodes of a platform. 

FIG. 5 depicts a logical view the multi-level hierarchy of the resource management unit 
with interfaces to jobs and nodes on lower level platforms. 

FIG. 6 depicts a logical view the multi-level hierarchy of the resource management unit 
with multiple universal coordinators at the universal level, with multiple group coordinators at 
the group level, with multiple local coordinators at the local level and with multiple agents at the 
agent level. 

FIG. 7 depicts an example of the implementation of a group level hierarchy with vertical 
integration of processes of the hierarchy on some nodes. 
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FIG. 8 depicts an example of the implementation of a group level hierarchy with vertical 
integration of levels of the hierarchy in single processes on some nodes. 

FIG. 9 depicts an example of the implementation of a group level hierarchy with horizon- 
tal integration of processes of the same levels on common nodes. 

FIG. 10 depicts details of fault-detection and correction during a simple job failure. 

FIG. 1 1 depicts recovery from a vertical failure. 

FIG. 12 depicts recovery from a horizontal failure. 

FIG. 1 3 depicts a conflict situation where multiple monitors replace a single failing ele- 
ment. 

FIG. 14 depicts examples of components relevant for financial services where the com- 
ponents are implemented as services on cluster computer system. 

FIG. 15 depicts an example of an e-commerce system using the components of FIG. 14. 

FIG. 16 depicts a logical view of the local job manager running with host agents at levels 
in the hierarchy above jobs running on nodes of a platform. 



Cluster Groups - FIG. 1 

In FIG. 1, a plurality of clusters 9 are distributed in different groups 5 including groups 
5-1, 5-2, 5-3, 5-G and connect through the networks 13 to form an e-commerce system 2. 
The groups 5 are organized on geographical, company, type of information processed or other 
logical basis. 

In one example, the groups 5 of clusters 9 in FIG. 1 are distributed geographically around 
the world. The group 5-1, for example, has clusters 9, and specifically clusters 9i, 9^1, lo- 
cated in Europe. Group 5-2, by way of example, includes clusters 9, and specifically clusters 92, 
9q2, located in Asia. Group 5-3, for example, includes clusters 9, and specifically clusters 93, 
9g3, located in the eastern United States and group 5-G, by way of example, includes clusters 
9, and specifically clusters 9g, 9qq, located in the western United States. 

In a geographic distribution example, the FIG. 1 worldwide e-commerce system 2 is con- 
trolled in different ways. In one example, each group 5 is in a different region of the world 
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where each region controls worldwide transactions during the principal business hours of that 
region and where the control shifts to another region when the principal business hours shift 
thereby implementing a "foUow-the-sun" operation. Since the principal business hours change 
as a fimction of time and location around the world, transactions that are principal at one point in 
time in one group 5 are shifted to another group 5 in another region at different times of day rela- 
tive to common time. 

In one embodiment of a foUow-the-sun operation, a single site for a group 5 is at one lo- 
cation in the world and that single site serves customers aroimd the world where primary access 
privileges for that site are passed in a follow-the-sun manner to different persons around the 
world. In that one embodiment, the primary access privileges participate in a follow-the-sun 
operation but the actual processing site does not change location in the world. In another em- 
bodiment of a follow-the-sun operation, multiple sites for multiple groups 5 at multiple locations 
in the world are enabled to serve customers around the world where the primary site for actual 
processing is re-designated from location to location so as to follow-the-sun. By moving the site 
of actual processing from one location (for example, Europe) to another location (for example, 
US) where the primary site is Europe during primary European hours and the primary site is US 
during primary US hours tends to achieve better performance and lower latency. The decision of 
when to switch over from one site to another can be controlled by the client or can be automated. 

In order to control the operations of the groups 5 of clusters 9, each group 5 includes one 
or more resource management units (RMUs) 8 for controlling the group operation. In one exam- 
ple, a resource management unit 8 is present in each cluster, whereby transactions are routed to 
different clusters in the same or different groups as a fimction of time or other parameters. Each 
resource management unit (RMU) 8 is associated with other processes including communication 
and fimction processes for supporting cluster operation and communication. 

In another example, the groups 5 of clusters 9 in FIG. 1 are organized based upon opera- 
tions of a single company or a group of companies. For example, group 5-1 includes all of the 
clusters 9 for a single company that service one geographic region (for example, Berlin) while 
group 5-2 includes all of the clusters 9 for the same company that service another geographic 
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region (for example, New York City). In such an example, resource management units (RMUs) 
8 control the group operations. 

In still another example where the groups 5 of clusters 9 in FIG. 1 are organized based 
upon operations of a single company, the group 5-1 includes all of the clusters 9 in that company 
that service a particular type of information (for example, one type of marketable instruments 
such as stocks) while group 5-2 includes all of the clusters 9 in that company that service another 
type of information (for example, another type of marketable instruments such as bonds or deriv- 
atives). In such an example, resource management units (RMUs) 8 control the group operations. 

The above examples illustrate that any combination of clusters 9 can be used to establish 
the common control functions within one or more groups 5 and wdthin the e-commerce system 2. 

Multiple Cluster Design. - FIG. 2 

In FIG. 2, typical ones of the clusters 9 of FIG. 1 are shown including clusters 9-1, 9-2, 
9-Cl. The cluster 9-1 is typical of clusters 9 and includes one or more nodes 51 shown as 
nodes Sl-lj, 51-los that are formed of one or more computers 43-1 1, 43-1 each computer 
having corresponding operating systems (OSs) 42-1 including operating systems 42-1 j, 42- 
Iqsj respectively. Processes 41-1 are distributed to execute on the nodes formed of operating 
systems 42-1 and computers 43-1 of cluster 9-1. The processes 41-1 of cluster 9-1 are organized 
as belonging to a service unit 44-1, a communications unit 45-1 and a resource management unit 



In FIG. 2, the service unit 44-1 includes the services Sj, and these services are 

the primary reason that cluster 9-1 exists. By way of example, if the primary purpose of cluster 
9-1 is to execute financial transactions in an e-commerce system, like the e-commerce system 
described in connection with FIG. 14, then the different services Sj, Sj, of the service unit 
44-1 correspond to some or all of the components 71-2, 71 -Co of FIG. 14. Each of the ser- 
vices of service unit 44-1 is partitioned into one or more jobs 30 for execution on a node 51. 

In FIG. 2, the communication unit 45-1 controls communications from and to the cluster 
9-1 and the other clusters 9-2, 9-Cl of FIG. 2. The communication unit 45-1 controls the 
intra-cluster communication with other communication units 45-2, 45-Cl of FIG. 2 over the 
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connection elements 67 and controls the extra-cluster communication external to the clusters 9 of 
FIG. 2 over the connection elements 68. 

In FIG. 2, resource management unit 46-1 includes, for example, processes that are units 
for fault tolerance, load balancing and persistent storage operations. 

While cluster 9-1 is typical of the clusters 9 of FIG. 1, each of the other clusters 9-2, 
9-Cl includes one or more nodes 51 shown as nodes 51-2i, 51-2os and so on to nodes 51-Cl,, 
51-Clos that are formed of one or more computers 43 that are shown as 43-2i, 43-2Ha, and 
so on to 43-Cl,, 43-ClHa, each computer having corresponding operating systems (OSs) 42 
including operating systems 42-2,, 42-2os and so on to 42-Cl|, 42-Clos, respectively. Pro- 
cesses 41-2 and so on to 41 -CI have jobs that are distributed to execute on the nodes formed of 
operating systems 42-2 and computers 43-2 and so on to operating systems 42-Cl and computers 
43-Cl of cluster 9-2, 9-Cl, respectively. The processes 41-2 and so on to 41 -CI of clusters 9-2 
and so on to 9-Cl are organized as belonging to service units 44-2 and so on to 44-Cl, communi- 
cations imits 45-2 and so on to 45-Cl and resource management units 46-2 and so on to 46-Cl. 

The communication processes of the communication unit 45 of FIG. 2 are ones that are 
suitable for the particular embodiment selected for the connection elements 67 and 68. The con- 
nection elements 67 and 68 are logical entities that rely on the necessary physical interconnec- 
tion of each of the clusters 9 and appropriate protocols for those interconnections. When the 
connection element 67 or 68 is implemented as a local area network using TCP/IP, for example, 
the processes of communication units 45 provide for IP address assignment and addressing as a 
means to control communication among the clusters 9. When the connection element is imple- 
mented using point-to-point switching, for example, the communication processes are those suit- 
able for providing point-to-point switching protocols for transferring data between clusters 9. 
Regardless of the implementation of elements 67 and 68, the processes of communication units 
45 provide a logically consistent interface among clusters 9 that permits both homogeneous clus- 
ters (using the same hardware computers and operating systems) as well as heterogeneous clus- 
ters (using different hardware computers and/or operating systems) to transfer data. Nodes, in 
addition to being of different hardware and operating systems, may also run heterogeneous 
applications. The reasons for heterogeneous applications include, for example, environments 
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where special hardware that is needed to run an application is only available on certain nodes or 
special software that is needed to run an application is only available on certain nodes (for exam- 
ple, software licenses). 

In one particular embodiment, the communication unit 45 uses object serialization to 
transmit messages (or other) objects from one of the communication units 45 to another one of 
the communication units 45. This operation is done by initiating a network connection (for ex- 
ample a TCP/IP connection), then serializing the message object into a datastream which is usu- 
ally buffered. The data stream is then transmitted by the transmitting communication unit 45 
over the connection element 67 operating with the TCPAP protocol to the receiving communica- 
tion unit 45 where it is de-serialized. In an example using the FIG. 14 system, one embodiment 
sends meta-data of a buy/sell order from the TI interface component 71-10 to the storage compo- 
nent 71-13 and subsequently to the crossing component 71-3. The Java Remote Method Invoca- 
tion (RMI) interface by Sun Microsystems can be used to implement such object serialization 
communication methods. 

For different message-types and embodiments of the connection element 67, the use of 
other communication protocols vdth different flow-control mechanisms, delivery guarantees and 
directory services are used. Various schemes over IP provide alternate embodiments. For exam- 
ple, heart-beat messages use the UDP/IP protocol because reliable delivery is not required. 
Communication protocols are not restricted to IP-based schemes, the only requirement is that 
both the transmitting cluster as well as the receiving cluster are capable of handling messages in 
a selected protocol. Other messaging systems, such as Remote Procedure Call (RPC) and Active 
Messages, are acceptable implementations as well. 

In other embodiments, higher-level (fast) messaging systems are used to communicate 
between clusters. Examples include TIBCO or NEON messaging layers which are again able to 
completely abstract the communication layer from the underlying hardware clusters and thus 
effectively act as middle-ware. Other middleware products include Talarian Smart Sockets, Java 
Message Queue and Vitria. 

In fiirther embodiments, multiple clusters run on the same hardware and operating system 
node using the same memory. In such embodiments, the same communication mechanisms are 
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used as described above. Additionally, specialized inter-process communication schemes can be 
used for improved performance and better use of system resources. 

In general, operations that are performed by the FIG. 2 system include jobs that execute 
to provide the services 44, include processes used in connection with the conununication units 
45 and the resource management units 46 and include operating system calls for operating sys- 
tems 42, memory controls and availability determinations, network access control and latency 
determinations and any other operations useful in or in connection with the computer system of 
FIG. 2. 

Process Architecture - FIG. 3 

FIG. 3 depicts a logical overview of the architecture of a set of processes 41 typical of 
the distributed sets of processes 41-1, 41-2, 41-Cl in the clusters 9 of FIG. 2. A typical set of 
process 41 in FIG. 3 includes the service unit 44 processes that are typical of the distributed ser- 
vice units 44-1, 44-2, 44-Cl in the clusters 9 of FIG. 2. The service unit 44 processes include 
the services 44i, 442, 443, 44s that are applications or functions that as a whole are typically 
distributed across multiple nodes of a cluster (that is, for cluster 9-1 of FIG. 2, across one or 
more computers 43-1 j, 43-lHa5 and corresponding operating systems 42-1,, 42-los5 respec- 
tively) or across nodes of multiple clusters. 

The set of processes 41 in FIG. 3 include the communication unit 45 processes that are 
typical of the distributed communication units 45-1, 45-2, 45-Cl in the clusters 9 of FIG. 2. 
The set of processes 41 in FIG. 3 include the resource management unit 46 processes that are 
typical of the distributed resource management units 46-1, 46-2, 46-Cl in the clusters 9 of 
FIG. 2. The resource management unit 46 includes a fault tolerance unit 46, for ensuring fault 
tolerant operation of the processes 41 and the clusters 9 on which they execute. The fault toler- 
ance unit 46, includes a job manager 48 for scheduling resources among the services 44„ 442, 
443, 44s. The resources scheduled include, for example, CPU time, disk and memory privi- 
leges and network bandwidth. While such resource management is a function that in conven- 
tional systems is usually performed by the operating system 42 on each node of a cluster 9 of 
FIG. 2, the distributed resource management unit 46 is provided to add fault tolerance, load-bal- 
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ancing, persistent storage and output capabilities to each cluster 9 and to the global e-conunerce 
system 2. 

For fault tolerance operation, if a hardware or software component fails on a node, the 
distributed resource management unit 46 through operation of the fault-tolerance unit 46, auto- 
matically restarts the component on the same or a different node. If possible, restarting on the 
same node is desirable since in this way the failure is fixed at a lower level without having to 
make a call to a higher level. If not possible to restart on the same node, the operation restarts 
the interrupted component on a different node. If a cluster failure occurs, or if non-failing other 
nodes on a cluster are not suitable for restarting the component, all services are then restarted to 
run on a different cluster. If a group of clusters fail, all services are scheduled to run on a differ- 
ent group of clusters. A group of clusters has redundancy and ordinarily is not expected to fail. 
However, group failure may occur in some disasters (such as an earthquake or other environ- 
mental calamity) but such occurrence is expected to be rare. In other situations, it may also be 
desirable to move services to another group of clusters without interrupting service. For exam- 
ple, planned maintenance, upgrades, load balancing and reconfiguration all may involve moving 
services among clusters and groups of clusters. 

For load balancing operation, the distributed resource management unit 46 through oper- 
ation of the fault-tolerance unit 462 detects when a particular resource in a cluster or group of 
clusters is being taxed or is likely to be taxed more than other comparable resources and takes 
appropriate action to reschedule some of the jobs to a less taxed resource, thereby achieving 
load-balancing. 

The distributed resource management unit 46 uses a persistent storage unit 463 in order to 
allow applications such as the services 44,, 442, ^^3^ 44s store state information about exe- 
cuting processes to non-volatile memory of persistent storage vmit 463 in a consistent way. Such 
state information typically includes computational results and data to checkpoint the executing 
application at restartable execution points. Checkpoints are selected to store operating parame- 
ters and progress of an application after major computational steps or at certain points in the exe- 
cution sequence. If a failure occurs, applications that operate with such checkpoints are restarted 
by the fault-tolerance unit 46, and/or the load-balancing unit 463 at the last successfiiUy com- 
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pleted checkpoint. Because the persistent storage facility 463 is part of the resource management 
unit 46, state information can be transparently replicated to remote sites, allowing immediate 
fail-over even in the case of a site failure. 

The interface unit 464 is part of the resource management unit 46. The interface unit 464 
collects and provides output information and receives input information and commands that al- 
low humans to monitor and control the computer system 2 (see FIG. 1) and each of the compo- 
nents and parts thereof. The interface unit 464 logs data and processes the logged data to form 
statistics about the overall system and about each component in the system includmg up-time, 
down-time, failure, performance, configuration, versions, through-put and other component and 
system information. The interface unit 464 provides data for system availability measurements, 
transaction tracking and other information that may be desirable or required. Such output data 
is useful for, among other things, satisfying obligations in service agreements with customers 
that require contracted levels of system availability and transaction tracking for satisfying legal 
or other obligations. The interface unit 464 has an internal unit 464., that provides full data and 
control to system administrators and others having authority to access the system for such full 
access. The interface unit 464 also has an external unit 464.2 that provides one or more levels of 
access to customers or others not having authority for full system access. Typically, the external 
unit is used by or for customers to monitor the overall availability of a service being delivered to 
the customers. 

There is a tradeoff between the interval of checkpointing and the amount of recomputa- 
tion needed upon failure. In some embodiments (based upon the current state of storage technol- 
ogy)^ a greater amount of recomputing is preferable over more frequent checkpointing. Each 
application that uses the framework may decide what is most effective for given hardware and 
software constraints and the application requirements. The decision of how often to checkpoint 
is to some degree application-specific. More frequent checkpoints slow dovm application per- 
formance and less frequent checkpoints require more computation to recover from failure. The 
best checkpoint frequency for each application is determined and used for operation. Another 
factor that affects checkpoint frequency is the publication of results. A checkpoint is also re- 
quired each time results are published outside of the cluster (for example, to a customer). The 
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checkpoint is require because recomputation does not necessarily produce identical results. 
Therefore, once results are published, recomputation is no longer an acceptable recovery strat- 
egy. 

Persistent storage can be distributed in many ways, for example, some embodiments dis- 
tribute storage over an entire cluster using RAID technology and other embodiments dedicate 
persistent storage to separate machines. 

The fault-tolerance framework described operates to keep processes running continu- 
ously by providing a hierarchy of monitors that are capable of restarting any failing process or 
migrating processes to different nodes on the network when a hardware or software failure is 
discovered. The hierarchy also makes sure that the individual monitors are running correctly. 

For applications that use processes that do not require state information (stateless pro- 
cesses), the fault-tolerance framework works well, is fast and does not require persistent storage 
because it is not important where the application is running or what data it was being processed 
before a failure. An example of an application that uses stateless processes is a web server that 
serves static HTML pages to clients regardless of which pages the client requested previously or 
of which pages other clients have requested in the mean time, hi this example, the fault-toler- 
ance framework need only operate to make sure that an adequate number of web servers are run- 
ning to ensure continuous availability of the service. In this example, the same client can be 
served by one server for one request and by another server for another request without any ap- 
parent change in the service as viewable by the client. 

For applications that use processes that do require state information (statefiil processes), 
the fault-tolerance framework works to preserve sufficient state information to enable restarting 
and transfer of processes. An example of an application using statefiil processes is a financial 
instrument crossing application in which, for example, stock shares of a buy order and a sell or- 
der are matched and crossed (that is, are bought and sold). In such a trading application, a trader 
submits an order to trade shares to an electronic market and, regardless of failure, the order must 
not be lost and must remain active in the system until it is executed, expires or is cancelled. Re- 
strictions on the orders and crossing need to be considered and properly processed even in the 
case of failures in the system during the processing. Also, normal trading rules need to be fol- 
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lowed. For example, the rule must be followed that each share can only be executed once 
against orders of the same kind on each side (buy with sell; sell with buy). 

In order to prevent failures from causing a stateful process from being lost altogether or 
improperly executed, a messaging layer with in the communication unit 45 routes and reroutes 
5 processing to avoid the consequences of failures as they occur. When the fault-tolerance frame- 
work transfers or restarts processes on different nodes, other processes need to be able to reach 
the rerouted or transferred processes after they have been migrated to new nodes. For example, 
if orders of a certain type are initially matched on one node but are subsequently migrated for 
matching to new node, a cancellation message for one of these orders needs to be routed to the 

10 new node automatically. Similarly, a new order for matching must be directed to the new node 
after migration. In operation, the messaging layer processes messages with logical destinations 

f=i that use a logical-to-physical translation that makes any physical transfer transparent to the af- 

2:f fected processes. 

fy When possible, the fault-tolerance framework only restarts processes once it ensures that 

45 the processes have actually failed. At times, however, there is a trade-off between how quickly a 
process can be restarted and how accurately it has been determined that the process has actually 
B failed. In some cases which are intended to be rarely occurring, a process is started or restarted 

G that did not fail so that one or more unintended instance of a process is executing at the same 
time as the intended instance. In a stateless system, restarting of a non-failed process or the oth- 
00 erwise starting of unintended duplicate processes is only a minor problem because the result is 
only that one additional process is activated in a non-conflicting way to handle requests. How- 
ever, in a stateful system, a process that is started as a replacement for a process that did not fail 
needs to be handled correctly and to ensure that the unintended duplicate processes do not cause 
data or process corruption. 

25 In order to control the operation of processes in an environment where unintended dupli- 

cate processes may occur, a persistent storage facility is used to store state data that is needed by 
the system to continue processing in an environment where unintended duplicate processes have 
or may occur because of system failures or because of other reasons. The stored state data is 
used, for example, with checkpoints in executing applications and processes to ensure coordina- 
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tion between execution states of the executing processes and the stored state data in the persis- 
tent store. The coordination between the executing process and their known states, the stored 
states in the persistent store and the control algorithms for controlling reliable processing in spite 
of failures and duplicates achieves highly reliable operation and availability. 

In order to ensure that indispensable processes can communicate, a messaging layer is 
used that interfaces with a directory service that is integrated with the fault-tolerance framework. 
The directory service operates to conveniently locate information in the framework thereby en- 
suring that a seamless operation results even in the presence of failures. 

The architecture of the processes 41 of FIG. 3 can advantageously utilize embodiments of 
the communication element 67 of FIG. 2 that interconnects the different nodes and services in 
one or more of the clusters 9. Typically, element 67 includes a different interconnect for com- 
munication local to one node from that of inter-node communications. In addition, inter-cluster 
communications and wide-area communications also likely use different communication mecha- 
nisms. The selection of components for the connection elements 67 is done consistently with the 
architecture of the processes 41 of FIG. 3. 

Local Job Manager - FIG. 4 

FIG. 4 depicts a logical view of the hierarchy of a local job manager 48 1, which is one 
embodiment of the job manager 48 of FIG. 3, together with the local platform 40 including the 
jobs 30 and nodes 51 on which the jobs execute. The nodes 51, including nodes 51-1, 51-N, 
in local platform 40 are any set of all or some of the nodes 51 for the clusters 9 of FIG. 2. These 
nodes 5 1 in FIG. 4 are implemented using suitable computational devices, such as workstations 
or mainframes, with single-processor or multi-processor configurations. The nodes 51 are the 
resources that are assigned for executing the jobs 30 that perform the services 44 of FIG. 3. 

In FIG. 4, the jobs 30, including jobs 30-1, 30-J are, for example, programs, threads, 
executable code or data structure tasks that are useful in providing data processing services 44. 
For fault-tolerant operation, the jobs 30 are monitored for proper operation, execution and termi- 
nation. Each job 30 runs on one node 51 and multiple jobs 30 can run on the same node 51 so 
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that there can be a many-to-one mapping of jobs to nodes. In FIG. 4, for example, Job 3 and Job 
4 both run on Node 3 in a two-to-one mapping. 

In FIG. 4, the agents 31, including agents 31-1, 31-A, are monitors that monitor the 
execution of the jobs 30. One agent 31 can monitor multiple jobs 30 running on multiple nodes 
51 or multiple CPUs if a node 51 is implemented with multiple CPUs. Multiple agents 31 can 
monitor different sets of jobs 30 on the same node 51. However, each job 30 is only monitored 
by one agent 3 1 . In one embodiment, each node 5 1 is associated with only one agent 3 1 and in 
such an embodiment the monitoring agent is called the host agent. In such an embodiment, the 
host agent 3 1 monitors all jobs 30 running on that node 5 1 . 

Each agent 31 includes fault-tolerant code (a) 32 that implements the fault-tolerant oper- 
ation of the agent 31. The fault-tolerant code 32 is implemented in various embodiments to 
monitor proper operation. In one example, the fault-tolerant code 32 makes checks using stan- 
dard operating system calls to see if the monitored job 30 is still running or if the job terminated 
successfully or unsuccessfully. Such checks (coupled with time-out values) also detect if the 
hardware resources as a whole are still available to run the job. However, these checks alone 
may not detect deadlocks, infinite loops or other situations in which the code execution of a job 
is not making sufficient progress towards delivering the desired service. Often, a continuous and 
explicit indication of progress is needed to detect such failures. Because indications of progress 
tend to be application specific, the fault-tolerant code 32 in one embodiment only watches for 
heart-beat messages or other indicators. Each application has code 49 in a service 44 that con- 
tains the required logic to respond appropriately depending on progress. If a job terminates un- 
expectedly or a resource becomes unavailable, the agent 31 watching the job is responsible for 
restarting that job either on the same one of the nodes 5 1 on which it was running before or on an 
alternate one of the nodes 5 1 . 

The code 32 for the agents 31-1, 31-A includes a suicide protocol that operates only 
on the logical level of agents 31. Each hierarchy level in the fault-tolerance unit 46, uses this 
suicide protocol and each job 30 is only monitored by exactly one agent 31. The FIG. 4 embodi- 
ment only has a local level corresponding to local coordinator 33. Additional levels are possible 
as described in connection with FIG. 5. 
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In FIG. 4, the local coordinator 33, monitors the executions by the agents 31-1,..,,31-A 
and executes the suicide protocol in the fault-tolerant code 34. The local coordinator 33 moni- 
tors one or more agents 31. Should an agent 31 fail, the local coordinator 33 in charge of that 
agent 31 is responsible for restarting the failing agent 31. In turn, each particular agent 31 
watches its corresponding local coordinator 33. In a case where the watched local coordinator 
33 fails, the corresponding particular agent 31 being watched that detects the local coordinator 
33 failure, restarts that local coordinator 33 or some alternate local coordinator such as local co- 
ordinator 33'. 

The number of agents 31 used to monitor jobs 30 relative to the number of jobs 30 exe- 
cuting depends on many factors. In one embodiment, one agent 3 1 is present for each node 5 1 . 
This allocation is desirable because, with such a configuration, a local job failure can be detected 
and corrected faster and cheaper (in terms of resources) because no network or external I/O oper- 
ation is needed. Similar benefits are derived from having an agent 3 1 only monitor a few nodes 
51. An important benefit results fi"om having one local coordinator 33 monitor many agents 31 
on different nodes because the agents 31 are collectively responsible for keeping their cor- 
responding local coordinator 33 alive. The likelihood of proper detection and correction of such 
a local coordinator 33 fault increases, because it is more likely that at least one of many agents 
31 will be healthy to notice the failure. It is often usefijl to have one local coordinator 33 per 
major application. If the resources are to be shared among multiple parties, each hierarchy level 
can allocate resources to specified parties. This allocation on a per party basis allows for fiill 
fault-tolerance and load-balancing benefits allocated on a per party basis where for a single het- 
erogeneous cluster it is guaranteed that each node is only used by one allocated party at a time, 
thereby effectively constructing a dynamic wall between parties. This configuration is usefiil for 
providing allocated services via an application service provider (ASP) running in a cluster envi- 
ronment shared by multiple parties while providing each party with a separate service level guar- 
antee in terms of the amount of dedicated resources that are allocated. 

Hierarchical Job Manager - FIG. 5 
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FIG. 5 illustrates job manager 48 in FIG. 3 in a multi-level hierarchical embodiment. In 
FIG. 5, the different hierarchical levels (namely, local, group and universal) connect from local 
coordinator 33 at the local level to group coordinator 35 at a group level to a universal coordina- 
tor 37 at a global level. All levels in this hierarchy have a suicide protocol implemented in the 
code 34, 36 and 38 of the local coordinator 33, group coordinator 35 and universal coordinator 
37, respectively. 

The group facility 52-1, in FIG. 5 includes local job managers 48-1 j ,, 48-L, l and 
platforms 40-1, ,, 40-L, l The local job managers 48 include the local coordinators 33-1, ,„ 
33-1, , L that are the same as the local coordinator 33 in FIG. 4. The local job managers 48 
include the agents 31-1, ,„ 31-1, , l and so on to the agents 31-1, , l, 31-1, , l that are the 
same as the agents 3 1 in FIG. 4. 

Each local job manager 48-1, ,, 48-L, l includes an instantiation of a two-level hierar- 
chy of monitors v^here agents 31 are one or more first monitors and local coordinator 34 is one 
of one or more second monitors. The one or more first monitors (agents 31) are for monitoring 
first operations (for example, jobs 30) and, for any particular one of the first operations that fails, 
the one or more first monitors (agents 31) operate for restarting another instance of the particu- 
lar one of the first operations. The one or more second monitors (local coordinator 34) are for 
monitoring the first monitors (agents 31) and, if any particular one of the first monitors fails (for 
example, agent 31-A, , ,), the one or more second monitors (local coordinator 33-1, , ,) operate 
for restarting another instance (another agent 31, for example, agent 31-1, , ,) of the particular 
one of the first monitors. 

The platforms 40 include the jobs 30-1, ,„ 30-1, ,l and so on to the jobs 30-1, ,l, 
30-1, , L that are the same as the jobs 30 in FIG. 4. The platforms 40 include the nodes 51-1, , ,, 
51-1, i L and so on to the nodes 51-1, , l, 51-1, , l that are the same as the nodes 51 in FIG. 
4. In the embodiment described, the group facilities 52 of FIG. 5 have the job manager and 
platform architecture of FIG. 4. In an altemate embodiment, other architectures for the group 
facility 52 are possible on the local level while retaining the overall hierarchical structure for 
group and/or universal levels. This altemate embodiment is useful, for example, for integrating 
existing legacy systems into the multi-level hierarchy of FIG. 5. 
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In FIG. 5, the group coordinators 35 are responsible for monitoring the local coordinators 
33. Accordingly, in one embodiment, the local coordinators 33 are monitored by the group coor- 
dinators 35 as well as by the agents 31 (as described in connection with FIG. 4). In alternate em- 
bodiments, monitoring of the local coordinators 33 is by one or the other of the group coordina- 
tors 35 or agents 31. 

Each group facility 52 and group coordinator 35 includes an instantiation of a three-level 
hierarchy of monitors where agents 31 include one or more first monitors, local coordinators 34 
include one of one or more second monitors and group coordinator 35 includes one of one or 
more third monitors. The third monitors (group coordinator 35) operate for monitoring the one 
or more second monitors (local coordinators 33) and, for any particular one of the second moni- 
tors that fails, the third monitors operate for restarting another instance of the particular one of 
the second monitors. The particular one of the third monitors (local coordinator 35-1 ,) that mon- 
itors the particular one of the second monitors (33-1 m) that fails runs on the same node (for ex- 
ample node 51-1, , i) or a different node (for example, node 51-Ni , ) than the node (node 51- 
1 , , ,) where the particular one of the second monitors that fails runs. 

Clusters 9 have platforms 40 that are grouped for monitoring in different ways. A group 
of clusters can consist of multiple local clusters at one location (for example, in the same build- 
ing complex) or can be widely distributed at locations around the world. The content and orga- 
nization of groups is described in connection with FIG. 1 . Further to the discussion in connec- 
tion with FIG. 1 , a group can, for example, consist of a single application that runs on different 
clusters. A group also can run a set of applications made available to a single customer. It is 
then possible to provide services to different customers at widely distributed data centers rather 
than at one centralized location. 

The universal coordinators 37 monitor the group coordinators 35 and they work together 
in the same way as the group coordinators 35 and the local coordinators 33 in that they each op- 
erate with a suicide protocol in code 38 and can detect and recover failures at the immediately 
lower level of the hierarchy. The universal coordinators 37 also are monitored by the lower level, 
in this case the corresponding group coordinators 35. The universal coordinators 37 are useful 
for monitoring an entire e-commerce system and are at the root of the hierarchical system and 
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hence provide a good starting point for human supervision. Again, it is possible to have multiple 
universal coordinators, for example, one for applications that are not mission critical (such as e- 
entertainment) and others for mission critical applications (such as e-commerce and financial 
markets). A failure of a universal coordinator does not mean a failure of the entire e-commerce 
system within the hierarchy of the universal coordinator but merely the failure of a monitor in 
that hierarchy. At each level, the location and number of the groups can be chosen v^isely to 
help avoid potential bandwidth restrictions and network delays. 

hi FIG. 5, the two-level relationship between the agents 31 and local coordinators 33 is 
the relationship of first and second monitors. Similarly, the two-level relationship between the 
local coordinators 33 and group coordinators 35 is the relationship of first and second monitors 
and the two-level relationship between the group coordinators 35 and the universal coordinators 
37 is the relationship of first and second monitors. 

Hierarchical Job Manager - FIG. 6 

FIG. 6 illustrates another representation of job manager 48 in FIG. 3 in a multi-level hier- 
archical embodiment like that of FIG. 5. In FIG. 6, each of the different hierarchical levels are 
shown aligned horizontally across the page including the universal level of universal coordina- 
tors 37, the group level of group coordinators 35 and the local level of local coordinators 33. 

In FIG. 6, the universal coordinators 37-1, 37-2, 37-U include the code 38-1, 38-2, 
38-U, respectively, each operating with a suicide protocol. Universal coordinator 37-1, by way 
of example, is the root of the group coordinators 35-1, 35-2, 35-U which include the code 38- 
1, 38-2, 38-U, respectively, each operating with a suicide protocol. Group coordinator 35-1,, 
by way of example, is the intermediary root of the local coordinators 33 in the group facility 52- 
1 1 which in turn include the instances of code 34, each instance operating with a suicide proto- 
col. Each local coordinator 33 is the intermediary root of corresponding agents which in each 
include instances of code 34 as indicated in FIG. 4, each instance operating with a suicide proto- 



col. 



The group facility 52-1 , in FIG. 6 is like the group facility 52-1, in FIG. 5. 
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Cluster Groups, Example I - FIG. 7 

FIG. 7 depicts an example of a snapshot in time of an implementation of the hierarchy 
described in FIG. 5 and FIG. 6. The nodes 51(N) represent a subset of nodes, like the nodes 51 
described in connection with FIG. 2 through FIG. 6, that are the hardware resources situated in 
5 two or more groups 5 where the groups 5 are of the type described in FIG. 1. In FIG. 7, the 
nodes 51(N) are in two groups named GROUP MEMBER G7, including node U and node V, 
and GROUP MEMBER GA^, including nodes W, X, Y and Z . Each vertical line originating at 
one of the nodes 51(N) in FIG. 7 represents a module of computer code executing on that node. 
For example, node U has three jobs (J) and one agent (A) executing as four different modules 
10 while node V has two jobs (J), one agent (A), one local coordinator (L) and one group coordina- 
tor (G) executing as five different modules. The universal coordinator U is executing on an ad- 
ditional node not shown in FIG. 7. In the embodiment of FIG. 7, the code for the G, L and A 
7^ levels of group member G7 are logical in nature in that physically they execute on the same node 
== ; (NODE V) as other processes J. The group member G7 processes with multiple levels G, L, A 
1^3 and J have all executing code sharing the same physical resources of a common node (NODE 

i V). 

FIG. 7 shows an example with an agent 31(A) executing on node U that monitors three 
C!J jobs (J) also executing on node U. FIG. 7 also shows another agent 31(A) executing on node Y 
f|l and monitoring jobs (J) on multiple nodes, specifically one job (J) on node Y and two jobs (J) on 
M node Z. FIG. 7 further shows a local coordinator 33(L) executing on node V while monitoring 
ri agents 31(A) with one agent (A) executing on node V and one agent (A) executing on node U. 
Because executing code often shares the same nodes, it is possible that the failure of a single ma- 
chine (for example NODE V) will bring down an entire sub-tree of the hierarchy of FIG. 7. In 
such a situation, the recovery may require multiple steps or, in this case, a single step will re- 
25 cover from multiple failures. However, it is possible to entirely eliminate such situations by as- 
signing certain hierarchy levels to a disjoint set of nodes as described in connection with FIG. 9. 
The advantage of the implementation in FIG. 7 is that there are no restrictions on where any 
code can execute and each level of the hierarchy is very close to the next lower level so that no 
major communication overhead is required. 
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Cluster Groups. Example 11 - FIG. 8 

FIG. 8 depicts an example of a snapshot in time of an implementation of the hierarchy 
described in FIG. 5. The nodes 51(N) represent a subset of nodes, like the nodes 51 described in 
connection with FIG. 2 through FIG. 6, that are the hardware resources situated in one or more 
groups 5 of the type described in FIG. 1. Each vertical line originating at one of the nodes 51(N) 
in FIG. 8 represents code in a code module executing on that node. For example, node X has 
two jobs (J) executing in two code modules and one job (Jx), one agent (Ax) and one local coor- 
dinator (Lx) all executing as part of a single code module. Node Y has a universal coordinator 
(Uy), a global coordinator (Gy) and an agent (Ay) all executing as code in a single module and 
has one job (J) executing as a separate process in a separate code module. Node Z has two jobs 
(J) executing in two different code modules. In the embodiment of FIG. 8 for the Node Y, the 
different levels of Uy, Gy, Ly and Ay are logical in nature in that physically they execute on the 
same node (NODE Y) along v^th another process (J) and hence all share the same physical re- 
sources. Logically, the different levels of elements of Uy, Gy, Ly and Ay are vertically hierarchi- 
cal in that Uy monitors Gy, Gy monitors Ly, Ly monitors Ay and Ay monitors J. The physical 
nodes and the code modules that are selected for the elements of Uy, Gy, Ly and Ay are deter- 
mined as part of the system design where factors considered in making the selection include 
node availability, fault tolerance and load balancing. 

In the FIG. 8 example, an agent Ax executing on node X monitors three jobs (J, J, Jx) 
executing on the same node (NODE X). In the FIG. 8 example, another agent Ay executing on 
node Y monitors jobs (J) on multiple nodes, specifically one job (J) on node Y and two jobs (J) 
on node Z. In the FIG. 8 example, local coordinator Lx executing on node X monitors agent Ax 
and local coordinator Ly executing on node Y monitors agent Ay. As is evident firom the FIG. 8 
example, executing code often shares the same nodes and the same code modules so that it is 
possible that the failure of a single machine (for example NODE Y) or a single code module v^ll 
bring dovra a substantial portion of the hierarchy of FIG. 8. In such a failure situation, the recov- 
ery may require multiple steps. However, it is possible to entirely eliminate such situations by 
assigning certain hierarchy levels to a disjoint set of nodes as described in connection with FIG. 
9. The implementation in FIG. 8 has the advantage that there are no restrictions on where any 
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code can execute and each level of the hierarchy is close to the next level so that no major com- 
munication overhead is required. 

Cluster Groups, Example III - FIG. 9 

FIG. 9 depicts another example of a snapshot in time of an implementation of the hierar- 
chy described in FIG. 5 with a different allocation of monitor elements than in FIG. 7 and FIG. 
8. In FIG. 9, the nodes 51(N) are in two groups named GROUP MEMBER Gl including node 
U and node V like in FIG. 7, and GROUP MEMBER GA^, including one or more nodes L and A 
and including muhiple nodes (J). The GROUP MEMBER GA^ in FIG. 9 differs from GROUP 
MEMBER GA^ in FIG. 7 in that in FIG. 9, the monitors at different levels are grouped at the 
same node, that is, the local coordinators 33(L) are both located on one or more L nodes, the 
agents 3 1(A) are located on one or more A nodes and the jobs 30(J) are located on one or more J 
nodes (J NODE 1, J NODE J). 

In FIG. 9, a specific set of nodes 51(L) for GROUP MEMBER GN is dedicated to run 
local coordinators (L) only. If one of the local coordinators L fails, agents (A) and the group co- 
ordinator (G) are only allowed to start a new local coordinator (L) on these dedicated L nodes. 
Typically, three nodes are sufficient to provide n+1 failure capabilities such that if one node is 
down for service and one node fails, the third node can still perform the job. Any number of 
nodes is possible. The principle of dedicated nodes for a level in the hierarchy can apply to all 
hierarchy levels where the use of L nodes for the L level of the hierarchy is extendable to G 
nodes for the G level, to A nodes for the A level and so on such that each level includes one or 
more dedicated nodes for that level. The universal coordinator U is executing on an additional 
node not shown in FIG. 9. In the FIG. 9 embodiment, for example, the nodes 51(A) for the agent 
level A are dedicated to running agents (A). In another embodiment, a combination of the dedi- 
cated and non-dedicated examples of FIG. 7 and FIG. 9 are employed in the same hierarchy. For 
example, the dedicated allocation in FIG. 9 can be applied only to the local coordinators L while 
an agent (A) appears on each node so that agents are not dedicated to any particular node. Such 
an embodiment helps prevent small errors from propagating to the group level while still allow- 
ing tree structures in part of the hierarchy. 
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Failure-Recovery: Single Job Failure - FIG. 10 

FIG. 10 illustrates the case of failure detection and recovery where the failure is a single 
job (J) failure. In FIG. 10, job 2 (30-DOWN) is assumed to have failed and prior to failure was 
running on node 51-Y. Agent 31-1, which was monitoring job 30-1 on node 51-X as well as job 
30-DOWN on 51-Y, detected the job 2 (30-DOWN) failure. The failure may have been caused 
by the failure of the entire node 51-Y or by any other cause. As soon as the agent 31-1 detects 
the failure, agent 31-1 immediately restarts the failed job, perhaps on node 51-Z if it is assumed 
for purposes of example that the entire node 51-Y failed. This restart is indicated by the broken 
line from node 51-Y to node 51-Z in FIG. 10. The restarted job on node 51-Z is labeled T (30- 
UP) because it is a new instance of the old job 2. In the general case as shown in FIG. 10, the 
failing node 51-Y is different from the restart node 51-Z. However, in one embodiment, a single 
host agent (A) on each node monitors all jobs since job failures are not anticipated to be due to 
failure of an entire node. In such a host agent embodiment, the host agent restarts the failing job 
2 on the same node 51-Y that the job 2 was running on prior to the failure provided the node 51- 
Y is able to receive a restarted job. 

The distributed resource management unit 46 of FIG. 3 (including the entire hierarchy of 
monitoring operations for agents, local coordinators, group coordinators and universal coordina- 
tors) monitors jobs at the application level. Because resource management unit 46 is only con- 
cemed about the health of a job, the cause of the failure is irrelevant and it does not matter 
whether the entire resource failed or if only an application failed. In either case, the goal of 
completing the job was not achieved. In order to prevent undesirable results from cases where a 
non-responding job is wrongfiiUy assumed to have failed, the operation of the persistent storage 
facility 463 effectively intervenes because it only accepts checkpoints and other data writes from 
jobs that are in good standing and rejects other jobs. When multiple instances of the same job 
are running, only one instance of the job is actually allowed to modify the contents of the persis- 
tent storage facility 463. Effectively and as soon as duplicate jobs are detected, the duplicates are 
killed. The condition of more than one instance of the same job running arises, for example, 
when a job is restarted based upon a wrong determination that the job failed and therefore both 
the non-failed job and the restarted job are concurrently present until the duplicate is killed. 
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Also, it is possible for duplicate jobs to occur when there are multiple monitoring agents for a 
single job. When more than one agent determines that a job has failed and both agents initiate a 
restart of the job before realizing that another agent has already restarted the job, duplicate jobs 
are started. For this is reason, one preferred embodiment has only one agent monitoring any par- 
ticular job. 

Failure-Recovery: Vertical Failure - FIG. 1 1 

FIG. 1 1 represents a generalized vertical failure condition in a hierarchy. A vertical fail- 
ure can occur for the entire tree from the universal level to the job level or for any sub-tree of the 
hierarchy. In FIG. 11, three levels of a hierarchy are shown, namely levels 90, 91 and 92. The 
procedures for fault detection and correction are preferably the same at each level and if so, the 
levels 90, 91 and 92 can represent any of the following sequences of levels: job, agent and local 
coordinator; agent, local coordinator and group coordinator; or local coordinator, group coordi- 
nator and universal coordinator. In the first case, the suicide module 93 does not necessarily exist 
(for jobs), whereas in the other cases, the suicide module is present. 

In FIG. 1 1, the example assumes that a vertical failure involving all of the items Q, R, S 
and T has occurred. The vertical failure can happen if an allocation of the type described in FIG. 
7 is employed. In such an allocation, a single node failure, for example node V, will cause mul- 
tiple layers of monitors and jobs running on this node to fail. There are two different procedures 
that can detect the vertical failure: 1) at each level, if there is an alive item that was watched by 
one of the now dead monitors, it will start up a new monitor and 2) if the parent of the failing 
sub-tree is alive, it can restart its child. 

For generality, the first case is shown in FIG. 1 1 where Item 91-IINT lost its parent 92- 
DOWN and restarts it. As soon as a new instance (92-UP) of the monitor 92-DOWN is alive 
again, it detects (by recovering its state from the persistent storage unit 463 of FIG. 3) that it was 
watching a process that is no longer present, namely 91 -DOWN, a peer of 91-IINT. So 91-IINT 
immediately restarts the job 91 -DOWN. As soon as the job 91 -DOWN is running again, it also 
detects two children that are missing, namely 90-DOWN including DOWN S and DOWN T. So 
91-IINT restarts 90-DOWN including DOWN S and DOWN T as well. 
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As indicated in FIG. 1 1, Q', R\ S' and T' are the new instances that replace Q, R, S and 
T, respectively. Naturally, like in the example of FIG. 10, each of the new instances of jobs and 
monitors can be started up on the same node or on a different node. In the one embodiment, 
workload information about each node, stored in persistent storage unit 463 of FIG. 3 or other- 
wise available, is used in determining where to start up new jobs and where to restart jobs that 
have failed. Generally, it is faster to recover from horizontal failures because it is a one-step 
process. In comparison, vertical failures need to recover each level in the failed hierarchy. This 
difference between horizontal and vertical failures suggests that a vertical hierarchy such as il- 
lustrated in FIG. 9 is preferable to the horizontally integrated hierarchy depicted in FIG. 10. 
However, vertical hierarchies provide a slightly better resource usage in the case of failure-free 
operation and the proper arrangement therefore can be decided on a case-by-case basis, after ex- 
amining the network latencies and other factors involved. 

Failure-Recovery: Horizontal Failure - FIG. 12 

FIG. 1 1 illustrates a generalized horizontal failure. In FIG. 12, three levels of a hierarchy 
are shown, namely levels 90, 91 and 92. The procedures for fault detection and correction are 
preferably the same at each level and if so, the levels 90, 91 and 92 can represent any of the fol- 
lowing sequences of levels: job, agent and local coordinator; agent, local coordinator and group 
coordinator; or local coordinator, group coordinator and universal coordinator. In the first case, 
the suicide module 93 does not necessarily exist (for jobs), whereas in the other cases, the sui- 
cide module is present. 

In FIG. 12, for purpose of an explanation it is assumed that the items R and S have failed. 
This failure could happen if a setup as described in FIG. 9 is used. In such a setup, a single node 
failure can cause multiple items of the same hierarchy level to fail. There are two different cases 
where procedures can detect the failure: 1) at each level, if there is an alive item that was 
watched by one of the now dead monitors, it will start up a new monitor and 2) alternatively, if 
the different parents of the failing level are alive, they can restart their children. 

Both cases are shown in FIG. 12. All of the items 90-IINT lost their parents and at the 
same time, item 92-IINT lost its children. Each of the items 90-IINT and the item items 92-IINT 
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can immediately restart the dead monitors 91. As indicated in FIG. 12, R' and S' are the new 
instances that are replace R and S. Naturally, like in the example of FIG. 10, each of the new 
instances of jobs and monitors can be started up on the same node or on a different node. In the 
one embodiment, workload information, stored in persistent storage unit 463 of FIG. 3 or other- 
wise available, about each node is used in determining where to start up new jobs and where to 
restart jobs that have failed. 

Failure-Recovery: Conflict Situation - FIG. 13 

FIG. 13 provides representation of a generalized conflict situation when restarting a mon- 
itor. In FIG. 13, three levels of a hierarchy are shown, namely levels 90, 91 and 92. The proce- 
dures for fault detection and correction are preferably the same at each level and if so, the levels 
90, 91 and 92 can represent any of the following sequences of levels: job, agent and local coordi- 
nator; agent, local coordinator and group coordinator; or local coordinator, group coordinator 
and universal coordinator. In the first case, the suicide module 93 does not necessarily exist (for 
jobs), whereas in the other cases, the suicide module 93 is present. 

FIG. 13 shows a similar view to the one in FIG. 12 except that in FIG. 12 multiple items 
detect a single failure and try to correct it independently. The result is that multiple monitors 
monitoring a job can possibly interfere with each other. 91-UPl, 91-UP2, and 91-UP3 are equiv- 
alent monitors of the same hierarchy level, and exactly this interference situation should be 
avoided. To achieve this goal of interference avoidance, a protocol is required, especially be- 
cause each of these monitors can potentially be located on different nodes or, in higher levels of 
the hierarchy, even possibly at remote locations around the world. 

These possibilities of interference are corrected through use of the suicide modules. The 
suicide modules announce their existence and check for heartbeats from their peers. If it tums 
out that multiple monitors are monitoring the same job, all but one monitor will commit suicide. 
In one embodiment, a uniqueness indicator, such as the unique NIC (network interface card) ID 
or IP address, is used and only the monitor running on the node with the highest uniqueness indi- 
cator stays alive, while all other equivalent monitors commit suicide. However, since it is possi- 
ble that multiple instances of the same monitor will get started on the same node so that the 
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node-based ID does not establish uniqueness, then the unique process ID for the monitor is used, 
by way of one example, to keep only the monitor with the lowest process ID, the monitors with 
higher process ID's conmiitting suicide. 

In order to avoid having to use suicide protocols frequently, one embodiment also uses 
methods to avoid such multiple redundant monitors form being started. In one method, when a 
failure is detected, every item that detects the failure applies a random back-off delay before at- 
tempting to start a new monitor. If there is still no heartbeat message after the back off, the re- 
start is triggered. In practice it was shown that the back-off is an effective method for avoiding 
multiple instances of redundant monitors. In an additional method, all peers are notified via a 
broadcast message that the restart of a monitor has taken place. As soon as the other peers re- 
ceive this broadcast message, they stop their restart attempts and start sending heartbeats again. 
In one embodiment, different back-off times were used for the local area and the wide area 
which, among other things, compensates for greater latency due to longer communication paths 
and times. 

In one implementation, the monitors initiate all heartbeat activity with the level below 
them. The absence of a heartbeat from the monitor alerts the monitored level to initiate recovery 
of the monitor. Duplicate monitors discover each other as they poll (heartbeat) the monitored 
processes. This polling is how the election process is effected. Each monitor sends it's election 
value to each monitored process. In the case of the coordinator/hostagent, the coordinator sends 
its election value to each host agent when it polls for heartbeat. The hostagent compares this 
election value with the one from previous polls and keeps the "best" one. This best value is re- 
turned in its responses to coordinator polls. A coordinator receiving a "better" election value 
back from a hostagent executes its suicide function since there is another coordinator running 
that has a "better" election value. Once a coordinator has polled all hostagents on the network, it 
can be sure it is the only coordinator left running. Until a new coordinator has completed one 
complete poll cycle, it behaves in a passive way. It does not perform recovery of other compo- 
nents and it does not perform load balancing. 
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Market Engine - FIG. 14 

The clustering system 2 of FIG. 1 is beneficially employed to implement components of 
a market engine in FIG. 14. Details of market engine having the components of FIG. 14 are de- 
scribed in the above-identified cross-referenced application entitled MARKET ENGINES HAV- 
ING EXTENDABLE COMPONENT ARCHITECTURE. The components 71-1, 71-2, 71- 
Co, are interconnected by connection element 67. The connection element 67 is a logical entity 
that provides the necessary physical interconnection and protocol for each of the components 71 . 

In FIG. 14, the components 71 include, for example, a routing component 71-1, a trigger 
component 71-2, a crossing component 71-3, a scripting component 71-4, a stock component 71- 
5, a bond component 71-6, a currency component 71-7, an options component 71-8, an account- 
ing component 71-9, a TI interface component 71-10, a T.P. interface component 71-11, a DA 
interface component 71-12, a storage component 71-13, a supervisor component 71-14 and other 
components 71-15, 71 -Co. One or more or all of the components 71 of FIG. 14 are imple- 
mented as services in the service unit 44 of FIG. 3. In this manner, the hierarchical fault toler- 
ance described in the embodiments of the present invention are applied to the market engine 
components of FIG. 14. 

E-commerce System - FIG. 15 

FIG. 15 depicts an e-commerce system that employs the fault-tolerance framework previ- 
ously described for performing e-commerce transactions. Transactions in the system of FIG. 1 5 
are initiated, in some instances, with transaction initiators 10 in transaction units 11, including 
units 11-1, 11-Tu where each of the units 11 includes transaction initiators lO'-l, lO'-TI. 
Transactions are processed, in some instances, in transaction processors 12. The transaction ini- 
tiators 10 and the transaction processors 12 are collectively referred to as transaction units 7. 
The transaction initiation and processing is supervised by one or more market engines 95, desig- 
nated as market engines 95-1, 95E. In some embodiments, one or more of the market engines 
95 are capable of initiating and processing transactions internally, having the equivalent of trans- 
Attorney Docket No.: ATAE1015DEL Express Mail Label No.:EL328296286US 
1015_00^7^20.fi.wpd Page 32 of 94 7/20/0-22:3 1 



53 



action initiators 10 and/or transaction processors 12 internal to the market engine, and are then 
characterized as integrated market engines. 

In FIG. 15, the transaction initiators 10 are, for example, users that include computers, 
terminals and other equipment and software usefiil for persons (individuals or companies) to 
electronically connect to an e-conunerce system. Altematively, the transaction initiators may be 
brokers. Brokers include computers, terminals and other equipment and software usefiil for per- 
sons (individuals or companies) acting as brokers for users to electronically connect to an e-com- 
merce system. The transaction initiators in FIG. 15 can be of the user-only type of transaction 
initiator, can be of the broker-user type of transaction initiator or can be of any other type. Any 
number of such transaction initiators 10 of different types can be used in an electronic system of 
FIG. 15 for initiating electronic transactions. As additional examples, hierarchies of brokers, 
fimds, institutions and users are included, such as broker-broker, user-user, broker-broker-user- 
user. A hierarchy in any depth or configuration can exist. 

The market engines 95 respond to initiated transactions and supervise interaction among 
the transaction initiators 10, the transaction processors 12 and the different market engines 95 to 
control the routing of the initiated transactions, the processing of transactions and the coordinat- 
ing, gathering, storing and distributing of information usefiil for transaction supervision and pro- 
cessing. In some embodiments, historical data is used in this routing process to take advantage 
of statistical patterns in the processing performed in external transaction processors. Such his- 
torical data includes execution price and depth of the market among others things. 

In the FIG. 15 system, the market engines 95 are able to access and maintain information 
about transactions collectively as well as about each of the individual transactions being pro- 
cessed in the market engines 95. Where high reliability in transaction handling is required, the 
connections among transaction units 7 and market engines 95 are redimdant or are otherwise 
configured to ensure high reliability and high availability using the fault-tolerance fi-amework 
previously described. 

In the FIG. 15 system, connections among the transaction initiators 10, the transaction 
processors 12 and the different market engines is generically shovra through networks 13, but it 
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is to be understood that such connections in networks 13 can include direct connections among 
the transaction initiators 10, the transaction processors 12 and the different market engines 95. 

In FIG. 15, the transaction processors 12 include one or more conventional (or non-con- 
ventional) exchanges 24. The exchanges include, for example, conventional exchanges 24-1, 

5 24-EX, which are, for example, the New York Stock Exchange (NYSE), Chicago Mercantile 
Exchange, National Association of Securities Dealers Automated Quotation System (NASDAQ), 
and other similar exchanges. In the FIG. 15 embodiment, the transaction processors include the 
altemative trading systems (ATS) and particularly, ATS 26-1, 26-AT. The transaction pro- 
cessors also include electronic communication networks (ECN) including the ECN 25-1, 25- 

10 EC. Any number of other transaction processors 27 are possible in the transaction processors 12 
of FIG. 15, and these are generically indicated as the other transaction processors 27-1, 27- 
OT. Other transaction processors include Clearing Houses for example. Some of the transaction 

J] processors 12 in FIG. 15 include data components for receiving or providing data relevant to 

^J; transactions and these data components are designated as the data components 28-1, 28-DA. 

1=5 Such data components typically provide information about one or more of the other transaction 
processors such as the exchanges 24, ECNs 25 and the ATSs but also can provide any other type 
of data such as weather data, company earnings, political and economic data and so forth. Also, 

Q the data components may store data, provide data for quotations and otherwise act in any capac- 

fu ity to serve or receive data of all types. 

2§ In FIG. 15, the functional flow of information is shown by broken lines, while physical 

Q connections of the transaction initiators 10, market engines 95 and transaction processors 12 are 
generally through direct cormections to the network 13 as shown by solid lines. 

Local Job Manager With Single Host Agent - FIG. 16 
25 FIG. 16 depicts a logical view of the hierarchy of a local job manager 48, which is one 

embodiment of the job manager 48 of FIG. 3, together with the local platform 40 including the 
jobs 30 and nodes 51 on which the jobs execute. The nodes 51, including nodes 51-1, ...,51 -N 
in local platform 40, are any set of all or some of the nodes 51 for the clusters 9 of FIG. 2. These 
nodes 51 in FIG. 16 are implemented using suitable computational devices, such as 
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workstations, servers or mainframes, with single-processor or multi-processor configurations. 
The nodes 51 are the resources that are assigned for executing the jobs 30 that perform the ser- 
vices 44 of FIG. 3. 

hi FIG. 16, the jobs 30, including jobs 30-1, 30-J are, for example, programs, threads, 
executable code or data structures that are useful in providing data processing services 44. For 
fault-tolerant operation, the jobs 30 are monitored for proper operation, execution and termina- 
tion. Each job 30 runs on one node 51 and multiple jobs 30 can run on the same node 51 so that 
there can be a many-to-one mapping of jobs to nodes. In the example of FIG. 16, Job 1 runs on 
Node 1, Job 2 runs on Node 2, Job 3 and Job 4 both run on Node 3 and Job J runs on Node N. 
By way of one example, a job 30 may be part of a crossing engine implementation which func- 
tions to cross buy and sell orders for financial instruments and may be allocated for a particular 
symbol (such as IBM, Intel or other traded stock instruments). That is, in one embodiment, one 
job may cross shares of IBM, another job may cross shares of Intel, a still another job may cross 
shares of Inktomi and so on. In another embodiment, a single job may cross shares of IBM, 
shares of Intel, shares of Inktomi and so on. 

In FIG. 16, the local job manager 48 is implemented as code modules including the 
Coordinator .java, Cluster.java, JobEntry.java, Node.java, and HostAgent.java modules. In the 
local job manager 48, the Coordinator .java, Cluster.java, and multiple instances of the 
JobEntry.java and Node.java modules are part of the local coordinator 33. Multiple instances of 
the HostAgent.java module are used in multiple instances of the Host Agent. In the example 
described, the Java language is employed for the modules but any other language such as C/C-I-+ 
can also be used to avoid the additional complexity introduced by the Java Virtual Machine 
(JVM). In one embodiment, the fault-tolerance framework is compiled to machine code. The 
implementation of the host agent is desirably kept simple (and therefore reliable) because it is 
the most important component (software and hardware) in the system for achieving overall sys- 
tem reliable operation. 

In the example described, system startup occurs when one or more machines start run- 
ning HostAgents. To start the HostAgents, a shell script HostAgent.sh is executed. The 
HostAgent.sh script is marked as a startup script in the operating system such that it executes 
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automatically whenever the system is rebooted. The HostAgent.sh script is also be executed by 
Coordinator. Java whenever the coordinator detects that a HostAgent is not responding. The 
HostAgent.sh script does the following: 

1) Defines the hostname where the HostAgent is to run 

2) Defines the port at which the HostAgent listens to commands 

3) Sets the permissions for reading and writing to this port among others 

4) Starts MEC.Hydra.HostAgent 

The "MEC.Hydra." prefix identifies all the programs that are in a common package and 
the filename that gets executed is HostAgent.class, which has HostAgent.java as its source code. 

In the example described, after system startup occurs and the shell script HostAgent.sh 
has executed, one or more machines start running HostAgents. If no Coordinator exists, the one 
or more HostAgents will initiate one or more Coordinators and one Coordinator will survive and 
take control. Then, the Coordinator .Java module manages overall control of the cluster of nodes 
51 in platform 40. The Coordinator.] ava module initializes the state of the system, handles pa- 
rameters and performs other house-keeping operations. The Cluster.java module maintains the 
state of the cluster of nodes 51 in platform 40. The Coordinator.] ava module uses the 
Cluster.java module to poll the host agents 31 (or altematively the nodes 51 directly) for the 
alive status of the nodes 51, tracks where jobs 30 are running and, in certain embodiments, 
moves jobs 30 when their nodes 5 1 become unavailable. The Node.java module maintains node 
level information and an instance of Node.java is initiated for each active node 51. The 
Node.java module tracks which jobs are running on each node 51, the node status and which ser- 
vices are available on each node. The JobEntry.java module manages information about each 
job running in the cluster of nodes 51 in platform 40 and an instance of JobEntry.java is initiated 
for each job and is referenced to the corresponding Node.java instance. 

In FIG. 16, host agents 31, including host agents 31-1, 31-N, are monitored by the 
local coordinator 33 and each HostAgent.java module monitors the jobs that are executing on a 
corresponding node. 

Examples of code modules representing one embodiment of FIG. 16 are included in the 
following lists including HostAgent.sh in LIST_1, Coordinator.] ava in LIST_2, Cluster.java in 
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LIST_3, JobEntry.java in LIST_4, Node.java in LIST_5, HostAgent-l.java in LIST_6 and 
HostAgent-2.java in LIST_7. 

The HostAgent-l.java module is an example used where one job executes crossings for 
multiple symbols and the HostAgent-2.java module is an example used where multiple jobs are 
run for executing crossings of symbols. The jobs can be allocated with one job per symbol, mul- 
tiple jobs per symbol, one job for an entire service, one job for a group of symbols or with any 
other configuration. When a job manages multiple symbols and such a job becomes unavailable 
on an otherwise functioning node, only the dying subset of the symbols that are processed on the 
functioning node need be restarted, hi addition, different types of jobs can be monitored by the 
same HostAgent, for example, a job for a shopping service and a job for a crossing service. The 
HostAgent-l.java module and the HostAgent-2.java module can each be run separately or to- 
gether, for example, on the same node. If run together, the message terminology can be harmo- 
nized where for example, the sendStopMessage command calls the killJob message and the 
sendStartMessage command calls the startJob command. 
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LIST 1: HostAgent.sh 
Copyright 2000 Market Engine Corporation 

package MEC.Hydra; 
## 

## This script starts the HostAgent. 

## It starts the RMI registry and host agent code in the background. 
## 

## First, start the RMI registry. 

HOSTAGENT_PORT=300 1 
/bin/rmiregistry $HOSTAGENT_PORT & 

## . 

## now start the HostAgent server program 

PERMIT_FILE=/home/hydra/permit 
HOSTNAME=^hostname^ 

/bin/java -Djava. security. pohcy=$PERMIT_FILE MEC.Hydra.HostAgent 
$HOSTNAME 
$HOSTAGENT_PORT & 

exitO 

## 
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LIST 2: Coordinator. Java 
Copyright 2000 Market Engine Corporation 



1 package MEC.Hydra; 

2 import 
3 

4 import 

5 // Example Coordinator uses Java and implements an RMI interface for communication 

6 public class Coordinator extends UnicastRemoteObject 

7 implements CoordinatorRMI { 

8 // 

9 // Constructors 
10 // 

LL public CoordinatorQ throws RemoteException { 
^ super(); 

FfJ 
Lit 

t5 II 

W II Private data 

n II 

ipj 

1^ \ private static String Hostname; // Local host of the Coordinator 

M private static Cluster cluster; // Cluster to supervise (coordinate) 

21 

22 // 

23 // Public methods 

24 // 

25 public static String getHostNameQ { 

26 String hostname; 

27 try{ 

28 InetAddress addr = InetAddress.getLocalHostQ; 

29 hostname = addr.getHostNameQ; 
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LIST 2: Coordinator.java 
Copyright 2000 Market Engine Corporation 



} catch (UnknownHostException err) { 
hostname = new String("iocalhost**); 

} 



return hostname; 



// 

// RMI callable methods 

// 

public String startJob(String jobname) throws RemoteException { 
String nodename; 

//System.out.println("Coordinator: startJob " + jobname); 
cluster.addJob(jobname); 

nodename = cluster.locateJob(jobname); 

//System.out.println("Coordinator: startJob: nodename " + nodename); 
return new String(nodename); 



// 

// Private methods 

// 

private static void pollQ { 
while (true) { 
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public String locate Job(String jobname) throws RemoteException { 
String nodename; 



nodename = cluster.locateJob(jobname); 



return new String(nodename); 





LIST 2: Coordinator .Java 
Copyright 2000 Market Engine Corporation 



57 try{ 

58 Thread.sleep(15 * 1000); 

59 } catch (hiterruptedException err) { 

60 // Ignore 

61 } 

62 //cluster.checkJobsO; 

63 // Notes or jobs can be checked here every n milliseconds. 

64 // In this case, n=l5 XI 000 = 15 seconds. However, in this example implementation, 

65 // the pollerQ method in cluster Java is used instead. 

66 } 

67 } 

68 public static void run boolean demo { 

6^ System.out.println("Coordinator must run on Dispatcher node"); 

Cn 

70 Hostname = getHostNameQ; 

1% cluster = new Cluster(Hostname); 

7S // Create and install a security manager 

13 if (System.getSecurityManagerQ = null) { 

14 System.setSecurityManager(new 
tS SecurityManagerO); 

a } 

II 

78 try { 

79 String rminame; 

80 Coordinator obj = new CoordinatorQ; 

81 rminame = Parameters.RmiName(Hostname, "Coordinator"); 

82 Naming.rebind(rminame, obj); 

83 System.out.println("Coordinator: bind " + rminame); 

84 } catch (Exception err) { 

85 System.out.println("Coordinator err: " + err.getMessageQ); 

86 err.printStackTraceQ; 

87 } 



88 
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89 if (demo) { 

90 Node node; 

91 // For illustration, some nodes are added here and the ' VECN' job is assigned 

92 // and started on each of the nodes. In deployment, no nodes are explicitly 

93 // assigned but they are rather detected by the coordinator when an agent 

94 // is started on a node. 

95 node = new Node("nasdaq", cluster); 

96 node.addProgram("VECN"); 

97 cluster.addNode(node); 

98 node = new Node("nyse", cluster); 

99 node.addProgram("VECN"); 
100 cluster.addNode(node); 

1 &S node = new Node("cbo", cluster); 

1 Oi node.addProgramC' VECN"); 

1 cluster.addNode(node); 

m } 

iQi } 

106 public static void main(String args[]) { 
1® run(true); 

II starts the coordinator and because demo is set to true, it will also start the 

\& //VECNjobon3nodes. 

1E5 } 

la 

Iff } 
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package MEC.Hydra; 



import 



••• 



import 

// Cluster is used by Coordinator - Java to keep track of jobs and nodes 
public class Cluster extends Thread { 

// 

// Private data 

// 

private String Hostname = null; 
private Hashtable nodes = null; 
private Hashtable jobs = null; 
private int nodecount = 0; 
private int jobcount = 0; 



// 

// Constructors 

// 

public Cluster (String hostname) { 
Hostname = hostname; 
nodes = new HashtableQ; 
jobs = new HashtableQ; 
startQ; 



// 

// Node methods 

// 

// Called when the coordinator detects a new node in the clusters or when it 
// explicitly starts a new node in the demo. 
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LIST 3 : Cluster.java 
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public void addNode(Node node) { 

String nodename = node.getNodeNameQ; 

if (! nodes.containsKey(nodename)) { 
nodecount-H-; 

nodes.put(nodename, node); 

} 

} 

// called if the coordinator detects the failure of an entire node or when a node is 
// removed for servicing 
public void removeNode(String nodename) { 
if (nodes.containsKey(nodename)) { 

nodes. remove(nodename); 

nodecount— ; 

} 



public Node getNode(String nodename) { 
if (nodes.containsKey(nodename)) { 

return (Node) nodes.get(nodename); 
} else { 
return null; 

} 



// Job methods 

// called whenever the coordinator starts (and begins monitoring) a new job 
// anywhere on the cluster, 
public void addJob(String jobname) { 
if (! jobs.containsKey(jobname)) { 
jobcount-H-; 

jobs.put(jobname, new JobEntry(jobname)); 

} 

} 

// called when a job terminated successfully or is no longer watched by 
// the coordinator. 

public void removeJob(String jobname) { 



Attorney Docket No.: ATAE1015DEL Express Mail Label No.:EL328296286US 

1015_00^7^20.fi.wpd Page 44 of 94 7/20/0-22:3 1 



LIST 3 : Cluster.java 
Copyright 2000 Market Engine Corporation 

67 if (jobs.containsKey(jobname)) { 

68 JobEntry job = (JobEntry) jobs.get(jobname); 

69 stopJob(job); 

70 jobs.remove(jobname); 

71 jobcoimt— ; 

72 } 

73 } 

74 public int countTobsQ { 

75 return jobcount; 

76 } 

77 public String locate Job (String jobname) { 
7& String nodename = null; 

7Mi //System.out.println("Cluster: locateJob: " + jobname); 

^ if (jobs.containsKey(jobname)) { 

8.1? //System.out.println("Cluster: locateJob: ok"); 

821 JobEntry job = (JobEntry)jobs.get(jobname); 

8=S nodename = job.getNodeNameQ; 

U } 

//System.out.println("Cluster: locateJob: nodename " + nodename); 

8jK retiim nodename; 

} 

89 // 

90 // private methods 

91 // 

92 // Find a running node that can accept more jobs. This version 

93 // finds the running node that has the fewest jobs. (For equal load distribution 

94 // upon startup). 

95 private Node findNode(String Progname) { 

96 Enimieration en; 

97 Node bestnode = null; 

98 for (en = nodes.elements(); en.hasMoreElementsQ; ) { 

99 Node node = (Node)en.nextElementO; 
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100 if (node.isRunningO) { 

101 if((bestnode = null)|| 

1 02 (node.countJobsO < bestnode.countJobsO)) 

103 bestnode = node; 

104 } 

105 } 

106 return bestnode; 

107 } 

1 08 // Find a running node that can accept more jobs. This version 

109 // finds the running node that has the fewest jobs. 

110 private Node findNodeQ { 
1 1% Enumeration en; 

1 ii Node bestnode = null; 

fc? - 

1 fB for (en = nodes.elementsQ; en.hasMoreElementsQ; ) { 

1 Node node = (Node)en.nextElementQ; 

1 f S if (node.isRunningO) { 

U§ if((bestnode = null)|| 

1 17 (node.countJobsQ < bestnode.countJobsO)) 

1 tS bestnode = node; 

m } 
m } 

IXB return bestnode; 

lis } 

123 private void startJob(JobEntry job) { 

124 Node node = findNode(); 

125 if(node!=null){ 

126 System.out.println("Cluster: startJob: node " + 

127 node.getNodeNameO + " job " + job.getJobName()); 

128 node,addJob(job); 

129 //routeOob); 

130 } 

131 } 

132 private void stop Job( JobEntry j ob) { 
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133 Node node; 

1 34 node = job.getNodeO; 

135 if(node!=null) 

136 node.removeJob(job); 

137 } 

1 3 8 private void fail Job( JobEntry j ob) { 

139 Node node = job.getNodeQ; 

140 node.failJobQob); 

141 } 

142 private void checkNodesQ { 

1 43 Enumeration en; 

1 System.out.println("Cluster: Available Nodes:"); 

l4§ for (en = nodes.elementsQ; en.hasMoreElementsO; ) { 

145^ Node node = (Node)en.nextElement(); 

14j node.poUNodeO; 

14| if (node.isRunningO) 

149 System.out.println("\tup " + node.getNodeNameQ); 

lift else 

1 5U System.out.println("\tdown " + node.getNodeName()); 

15fi } 

15f } 

IM private void checkJobsQ { 

1 5 5 Enumeration en; 

156 for (en = jobs.elementsQ; en.hasMoreElementsQ; ) { 

157 JobEntry job = (JobEntry)en.nextElement(); 

158 if Gob.isRunningO) { 

1 59 Node node = job.getNodeQ; 

160 if (Inode.isRunningO) { 

161 failJobGob); 

162 } 

163 } else { 

1 64 String jobname = job.getJobName(); 

165 startJob(job); 

166 } 
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167 } 

168 } 

169 private void pollerQ { 

170 System.out.println("Hostname: " + Hostname); 

171 System.out.println("Cluster: poller"); 

172 while (true) { 

173 try { 

174 Thread.sleep(10000); 

1 75 // In this example, nodes and jobs are polled every 1 0 seconds. 

176 } catch (InterruptedException e) { 

177 //Ignore 

178 } 

1 7§ checkNodesQ ; 

llfl checkJobsO; 

m } 

180 } 

=?= 

1 84 public void run() { 

pollerO; 

1 85 // Cluster.java is used by coordinator.java as a thread. When the thread is run, 
18^ // Cluster.java automatically starts polling the nodes and jobs in behalf of the 
ISi //coordinator. 

m } 

IID } 
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1 package MEC.Hydra; 

2 import . . . ; 
3 

4 import . . . ; 

5 // used by cluster .Java to keep to keep track of its jobs and the states of each job. 

6 // These are mostly synchronized to ensure proper state transitions. 

7 public class JobEntry { 

8 public static int IDLE = 0; 

9 public static int WANTRUN = 1 ; 

1 0 public static int STARTING = 2; 

1 1 public static int RUNNING = 3; 

12 public static int WANTSTOP = 4; 
% public static int STOPPED = 5 

Cm 
W 

private Node node = null; 

t§ private String progname = null; 

private String jobname = null; 

t8 private boolean debug = false; 

2Q 

2| protected int state = IDLE; 
22 

23 // 

24 // Constructors 

25 // 

26 public JobEntry(String progname. String jobname) { 

27 this.progname = new String(progname); 

28 this.jobname — new String(jobname); 

29 } 
30 

31 
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// 

// public methods 

// 

// Deprecated 

pubUc JobEntry(Stringjobname) { 
this("VECN"Jobname); 

} 

public void setDebug(boolean d) { 
debug = d; 

} 

public synchronized boolean isRunningQ { 

return ((state != IDLE) &«& (state != STOPPED)); 

} 

public synchronized boolean isStopped() { 

return ((state = IDLE) || (state = STOPPED)); 

} 

public synchronized String getProgNameQ { 
return new String(progname); 

} 

public synchronized String getJobName() { 
return new String(jobname); 

} 

public synchronized String getNodeNameQ { 
String nodename = null; 

if (node != null) { 
nodename = node.getNodeNameQ; 

} 

return nodename; 

} 

public synchronized Node getNodeQ { 
return node; 

} 
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64 public synchronized boolean addJob(Node node) { 

65 if(state = IDLE) { 

66 if (debug) 

67 System,out.println("JobEntry: addJob " + jobname + 

68 " on " + node.getNodeNameO); 

69 state = WANTRUN; 

70 this, node = node; 

71 return true; 

72 } 

73 System.out.println("JobEntry: addJob '* + jobname + 

74 " on " + node.getNodeNameO + " failed, state " + state); 

75 return false; 

76 } 

public synchronized boolean removeJobQ { 
7i if (state = STOPPED) { 

W if (debug) 

System.out.println("JobEntry: removeJob " + jobname + 
?t " on " + node.getNodeNameO); 

8| state = IDLE; 

node = null; 

&4 return true; 

fa } 

m if(state==IDLE) { 

81 System.out.println("JobEntry: removeJob " + jobname + " failed"); 

8^ } else { 

System.out.println("JobEntry: removeJob " + jobname + 

# " on " + node.getNodeNameO + " failed, state " + state); 

91 } 

92 return false; 

93 } 

94 public synchronized boolean startJob() { 

95 if (state = WANTRUN) { 

96 if (debug) 

97 System.out.println("JobEntry: startJob " + jobname + 

98 " on " + node.getNodeNameO); 

99 state = STARTING; 

100 return true; 

101 } 

102 if(state = IDLE) { 

Attorney Docket No.: ATAE1015DEL Express Mail Label No.:EL328296286US 

ioi5_oo'X)7'^20.fi.wpd Page51of94 7/20/0-22:31 



LIST_4: Jobentry.java 
Copyright 2000 Market Engine Corporation 



103 
104 
105 
106 
107 
108 
109 

110 
111 
112 
113 
114 
115 

m 
m 
ifi 
111 

12Q 

m 

122 
123 
12lt 

m 

riJ 
126 

m 

129 
130 
131 
132 
133 
134 
135 
136 
137 
138 
139 
140 
141 



System.out.println("JobEntry: startJob " + jobname + " failed"); 
} else { 

System.out.printlnC'JobEntry: startJob " + jobname + 

" on " + node.getNodeNameO + " failed, state " + state); 



public synchronized boolean startedJobQ { 
if (state = STARTING) { 
if (debug) 

System.out.println("JobEntry: startedJob " + jobname + 
" on " + node.getNodeNameO); 

state = RUNNING; 
return true; 

} 

if (state = IDLE) { 

System.out.printlnC'JobEntry: startedJob " + jobname + " failed"); 
} else { 

System.out.println("JobEntry: startedJob " + jobname + 

" on " + node.getNodeNameO + " failed, state " + state); 

} 

return false; 



public synchronized boolean stopJobQ { 
if(state=- RUNNING) { 
if (debug) 

System.out.printlnC'JobEntry: stopJob " + jobname + 
" on " + node.getNodeNameO); 

state = WANTSTOP; 
return true; 

} 

if(state = IDLE) { 

System.out.printlnC'JobEntry: stopJob " + jobname + " failed"); 
} else { 

System.out.printlnC'JobEntry: stopJob " + jobname + 

" on " + node.getNodeNameO + " failed, state " + state); 

} 

return false; 
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142 public synchronized boolean stoppedJobQ { 

1 43 if (state = WANTSTOP) { 

144 if (debug) 

145 System.out.println("JobEntry: stopJob " + jobname + 

146 " on " + node.getNodeNameO); 

147 state = STOPPED; 

148 return true; 

149 } 

150 if (state = IDLE) { 

151 System.out.println("JobEntry: stopJob " + jobname + " failed"); 

152 } else { 

153 System.out.println("JobEntry: stopJob " + jobname + 

1 54 " on " + node.getNodeNameO + " failed, state " + state); 

155 } 

1 56 return false; 
iM } 

1 58 public synchronized boolean failJobQ { 

1 % if ((state = IDLE) || (state = STOPPED)) { 

1 It System.out.println(" JobEntry: failJob " + jobname + " failed"); 

10^ return false; 

162 } 

\% if (debug) 

lift System.out.println(" JobEntry: failJob " + jobname + 

1 % " on " + node.getNodeNameO + 

16^ " failed, state " + state); 

\m state = IDLE; 

ld(S node = null; 

169 return true; 

170 } 
171 

172 } 
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1 package MEC.Hydra; 

2 import 
3 

4 import 

5 // used by Cluster Java to keep track of its nodes and the states of these nodes. 

6 // Some of these are synchronized to ensure proper state transitions. 

7 public class Node { 

8 public static int IDLE = 0; 

9 public static int RUNNING = 1 ; 

10 public static int STOPPED = 2; 

11 

i% private Cluster cluster; 

£X private String name; 

1 ft private long oldID = 1 ; 

11 private long newID = 0; 
tig private Hashtable jobs; 

W private HashSet programs; 

t§ private int state = IDLE; 

F9 private int jobcount = 0; 

id 

ih II Constructors 

22 // Create a new cluster node assigning it the name 'name* 

23 // and linking it back to its parent cluster. 

24 public Node(String name. Cluster cluster) { 

25 this.name = new String(name); 

26 this.cluster = cluster; 

27 programs = new HashSetQ; 

28 jobs = new HashtableQ; 

29 } 

30 

3 1 // Node methods 
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32 public String getNodeNameQ { 

33 return name; 

34 } 

35 public boolean isRunningQ { 

36 return (state == RUNNING); 

37 } 

38 // Program methods 

39 public void addProgram(String progname) { 

40 System.out.println("HostAgent: addProgram " + progname); 

41 if (! programs.contains(progname)) { 

42 // Add program to our list 
4^ programs.add(progname); 

441 Start up the program 

4^ startProgram(progname); 

4& } 

4$ } 

48 public void startProgram(String progname) { 

493 System.out.println("HostAgent: startProgram " + progname); 

5W } 

m 

si: II Job methods 

ST public void add Job(JobEntry job) { 

53 if(job.addJob(this)){ 

54 jobs.put(job.getJobName(), job); 

55 jobcount++; 

56 startJob(job); 

57 System.out.println("Node " + name + 

58 addJob: jobcount " + jobcount); 

59 } 

60 } 

61 public void removeJob(JobEntry job) { 

62 if (job.isRunningO) 

63 stopJob(job); 
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64 jobcount--; 

65 jobs, remo veG ob) ; 

66 System.out.println("Node" + name + 

67 removeJob: jobcount " + jobcount); 

68 } 

69 public void failJob(JobEntry job) { 

70 if (job.isRunningO) 

71 job.failJobO; 

72 jobcount--; 

73 j obs.remove(j ob); 

74 System.out.println("Node " + name + ": failJob: jobcount " + jobcount); 

75 } 

IB public int countJobsQ { 
W return jobcount; 

f§ } 

Si| // Private methods 

SJ private void startJob(JobEntry job) { 
82 String jobname = job.getJobNameQ; 

O String progname = job.getProgNameQ; 

Sif String rminame; 

W tmpTimer ti = new tmpTimer(Thread.currentThread(), 5000); 

86 try { 

87 job.startJobO; 

88 rminame = Parameters.RmiName(name, "Coordinator"); 

89 HostAgentRMI ha = (HostAgentRMI) Naming.lookup(rminame); 

90 ha.startJob(progname Jobname); 

91 ti.cancelQ; 

92 job.startedJobO; 

93 } catch (Exception e) { 

94 ti.cancelQ; 

95 } 

96 } 

97 private void stop Job(JobEntry job) { 
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98 String jobname = job.getJobNameO; 

99 String progname = job.getProgNameQ; 

100 String rminame; 

1 0 1 tmpTimer ti = new tmpTimer(Thread.currentThreadO, 5000); 

102 try { 

103 rminame = Parameters.RmiName(name, "Coordinator"); 

1 04 HostAgentRMI ha = (HostAgentRMI) Naming.lookup(rminame); 

1 05 ha.stopJob(progname, jobname); 

106 ti.cancelQ; 

1 07 job.stoppedJobQ; 

108 } catch (Exception e) { 

109 ti.cancelQ; 

110 } 
l\\ } 

1 1^ // polls the nodes (host agents) every n milliseconds. In this case, n = 5 seconds. 

1 |ft // This example uses RMI to conmiunicate. 

1 ff^ public void poUNodeO { 

1 15 String rminame; 

1 tS tmpTimer ti = new tmpTimer(Thread.currentThread(), 5000); 

U : 

1 17 //System.out.println("Node: poUNode: begin " + name); 

IR try{ 

1 19. rminame = Parameters. RmiName(name, "HostAgent"); 

1 ^fl HostAgentRMI ha = (HostAgentRMI) Naming.lookup(rminame); 

12| newID = ha.getlnstancelDQ; 

m ti.cancelQ; 

12% //System.out.println("Node: newID: " + newID); 

124 ha = null; 

125 state = RUNNING; 

126 //System.out.println("Node: pollNode: end " + name); 

127 } catch (Exception e) { 

128 ti.cancelQ; 

129 newID = 0; 

130 state = STOPPED; 

131 //System.out.println("Node: pollNode: failed " + name); 

132 //System.out.println("Node: pollNode: e: " + e.getMessageQ); 

133 } 

134 } 

135 public void pollJobsQ { 
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139 
140 
141 
142 
143 
144 
145 

146 



IF' 



for (Enumeration en = jobs.elementsO; en.hasMoreElementsO; ) { 
JobEntry job = (JobEntry) en.nextElementQ; 
if (job.state = job.WANTRUN) { 

//stopJob(job); 

startJob(job); 
} else if Gob.state = job.WANTSTOP) { 

stopJob(job); 
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LIST 6: HostAgent-1 Java 
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package MEC.Hydra; 

import 

import 

// In this example, one host agent is run on each node and a node is only 'active' to the 
// cluster if the host agent is in good health. 

public class HostAgent extends UnicastRemoteObject implements HostAgentRMI { 



8 
9 
10 



Constructors 



public HostAgentO throv^s RemoteException { 
superQ; // redundant 

// Run RMI registry service internally 

reg = LocateRegistry.createRegistry(Parameters.RMI_PORT); 

jobs = new HashSetQ; 

sender = new Sender("localhost", 2000); 



19 
20 
21 



II 

II Private data 

II 



22 
23 
24 
25 
26 
27 
28 
29 



private Registry reg = null; // Registry 

private static String Hostname; // Local hostname 

private static String coordinatorHost; // Coordinator's hostname 

private static long instancelD; // Unique ID for this HostAgent 

private HashSet jobs; // List or running jobs (symbols) 

private Sender sender; 

// Communication node for VeCN 
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30 
31 
32 

33 
34 

35 
36 
37 
38 
39 
40 

43i 

42 

01 

44 
4^ 

m 
i 

51 

52 
53 

54 
55 
56 
57 
58 

59 



Public methods 



public static String getHostNameQ { 
String hostname; 

try{ 

InetAddress addr = hietAddress.getLocalHostQ; 
hostname = addr.getHostNameQ; 
} catch (UnknownHostException err) { 
hostname = new String("localhost"); 



// Return this HostAgent's unique instance identifier. This value 
// is different each time the HostAgent is started and is used by 
// by the Coordinator to check if the HostAgent is alive. At the 
// same time, the HostAgent checks if the Coordinator has asked it 
// for its ID in the past n milliseconds and restarts the 
// Coordinator if it has not. So checking goes both ways. 

public static long previous_call; 

public long getlnstancelDQ { 

previous_call = SysternxurrentTimeMillisQ; 

return instancelD; 



// This method is called periodically in order to restart the 
// Coordinator if it is not running anymore. In the case that 
// multiple instances of the Coordinator get started, they 
// detect each other and all but the Coordinator with the smallest 
// IP address and process id commit suicide 

public void checkCoordinatorQ { 
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60 if (System.currentTimeMillisO - 5000 > previous_call) 

61 { 
62 

63 // restart coordinator because we haven't heard 

64 // from it in over 5 seconds! 

65 } 

66 } 
67 

68 pubUc void setCoordinatorHost(String host) { 

69 coordinatorHost = host; 

70 } 

13 public String getCoordinatorHostQ { 

return coordinatorHost; 

\ y 

II Start a job on the local nodecontroUer (VeCN) - in this example, the VECN job is 

7=5 // assured to run and starting a new job means sending a message to the VECN and 

7^ // telling it to add the processing of a new symbol. Alternatively, actual processes 

17 could 

IS // be started as illustrated in Host Agent-2.java. 

79 public boolean startJob(String progname, String jobname) { 

W String fullname = progname + "/" + jobname; 

M II Confirm job is not running here 

if (! jobs.contains(fullname)) { 

83 // Add job to our list 

84 jobs.add(fullname); 

85 // Tell NodeContoUer (VeCN) to start running job (symbol) 

86 sendStopMessage(jobname); 

87 sendStartMessage(jobname); 

88 System.out.println("HostAgent: started " + fullname); 

89 } 

90 return true; 

91 } 
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92 // Start a job on the local node controller (VeCN). In this example, the VeCN job 

93 // is assumed to run and starting a new job means sending a message to the VeCN, 

94 // signaling it to add a new symbol. Alternatively, actual processes can be 

95 // started, as illustrated in HostAgent-2.java. 

96 public boolean startJob(String jobname) { 

97 return startJobC' VECN", jobname); 

98 } 

99 // Stop a job (symbol) running on the local nodecontroller (VeCN) 

100 public boolean stopJob(String progname. String jobname) { 

101 String fullname = progname + + jobname; 

102 // Is job running here? 

101 if Gobs.contains(fullname)) { 

1 (p // Remove job from our list 

1 (ffi jobs.remove(fullname); 

1 06 // Tell local NodeControUer (V eCN) to stop running job (symbol) 

1 OP sendStopMessage(jobname); 

IQS System.out.println("HostAgent: stopping " + fullname); 

fl \ 

110 return true; 
ifS } 

CSS. 

c z 

112 // Stop a job (symbol) nmning on the local nodecontroller (VeCN) 

1 1 3 public boolean stopJob(String jobname) { 

1 14 return stopJob("VECN", jobname); 

115 } 

116 // Stop all jobs running 

1 1 7 public void stopAllJobsQ { 

118 String jobname; 

119 //Go through list of jobs and stop each one 

120 for (Iterator it = jobs.iteratorQ; it.hasNextQ; ) { 

1 2 1 jobname = (String)it.next(); 
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stopJob(]obname); 

} 

} 

public boolean checkJob(String jobname) { 
if (jobs.contains(jobname)) { 

return true; 
} else { 
return false; 



// 

// Private methods 

// 

// Send a message to local NodeController (VeCN) to start job (symbol) 
private void sendStartMessage(String jobname) { 
CUSIP cusip - new CUSIPGobname); 

ActivateSymbolMessage message = new ActivateSymbolMessage(cusip); 
if (sender. SendMessage(message, true)) { 

sender.FlushBuffersQ; 
} else { 

System.out.println("HostAgent: sender failed"); 

} 

} 

// Send a message to local NodeController (VeCN) to stop job (symbol) 
private void sendStopMessage(String jobname) { 
CUSIP cusip = new CUSIPGobname); 

DeactivateSymbolMessage message = new DeactivateSymbolMessage(cusip); 
if (sender. SendMessage(message, true)) { 

sender.FlushBuffersQ; 
} else { 

System.out.println("HostAgent: sender failed"); 

} 

} 



} 
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157 // This method starts up the communication infrastructure and assigns an ID to itself. 

158 // After this, it is ready to accept jobs or other commands from the coordinator. 

159 public static void runQ { 

1 60 Hostname = getHostNameQ; 

161 // Create and install a security manager 

162 if (System.getSecurityManagerQ = null) { 

1 63 System. setSecurityManager(new RMISecurityManagerQ); 

164 } 

165 Date now = new Date(); 

1 66 instancelD = now.getTimeQ; 

1 ti II Register with RMI 

li try{ 

16^ String rminame; 

lip HostAgent obj = new HostAgentQ; 

17P rminame = Parameters.RmiName(Hostname, "HostAgent"); 

172^ Naming.rebind(rminame, obj); 

l'^ System.out.println("HostAgent: bind " + rminame); 

} catch (Exception err) { 
System.out.println("HostAgent err: " + err.getMessageQ); 

1 7^ err.printStackTraceO; 

m } 

m } 

179 

180 // Main - usually called when a node is started up (see shell script). 

1 8 1 public static void main(String args[]) { 

182 runO; 

183 } 

184 } 
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1 package MEC.Hydra; 

2 import 
. 3 ••• 

4 import 

5 // This is a second version of the HostAgent that can easily be used in conjuction with 

6 // the first version to get an extended implementation. 

7 /** 

8 * JOB THREAD CLASS 

9 * 

10 * This class is used to fork threads for jobs that the HostAgent 

1 1 * needs to keep track of. 

12 * Given the name of the Java program to be called, it will invoke 
O * the main program for that class. 

jlp * */ 

Cfi 

f S class JobThread implements Runnable { 

ij private int MAXARGS = 256; 

private String prog; 

i8 private String [] args; 

Wl private int numArgs; 

• F = 

2Jf public JobThread(String cmd) { 

err 

22 args = new String [MAXARGS]; 

23 parseCommand(cmd); 

24 } 

25 

26 /* * parseCommand - 

27 * code to parse the program and arguments from 

28 * the command string. This could also be done with built-in functions. 

29 */ 

30 public void parseConmiand(String cmd) { 

31 int space! = 0; 

32 int space2 = 0; 
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33 space2 = cmd.indexOf(" spacel); 

34 if(space2 = -l) { 

35 space2 = cmd.lengthQ; 

36 } 

37 prog = cmd.substring(spacel, space2); 

38 numArgs = 0; 

39 while (space2 < cmd.length()) { 

40 spacel = space2 + 1; 

41 space2 = cmd.indexOf(" spacel); 

42 if(space2 = -l) { 

43 space2 = cmd.lengthQ; 

44 } 

45 args [numArgs] = cmd.substring(spacel, space2); 

46 numArgs-H-; 

m if (numArgs >= MAXARGS) { 

48 System.err.println("Not enough space in args struct"); 

4!^ retum; 

59 } 

% } 

E 

5§ // System.err.println("parseCommand: prog is " + prog + numArgs is " + 
53 numArgs); 

III // for (int i = 0; i < numArgs; i-H-) { 

5S // System.err.println("arg " -h i + " is " + args[i]); 

m II } 

S3 } 



58 /**run-- 

59 * call the jobThread classes main with specified command-line 

60 * arguments. 

61 */ 

62 public void runQ { 

63 // System.out.println("Starting job thread"); 

64 Class paramTypes [] = {(new String[0]).getClassO}; 

65 try { 

66 Class which = Class.forName(prog); 
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67 Object obj = which.newInstanceQ; 

68 java.lang.reflect.Method method = which.getMethod("main", paramTypes); 

69 Object[] invokeArgs = new Object[l]; 

70 invokeArgs [0] = args; 

71 method.invoke(obj, invokeArgs); 

72 } 

73 catch (Exception err) { 

74 System.err.println(err.getMessageO); 

75 err.printStackTraceO; 

76 } 

77 } 

i } 

3B 



3 

Q ■ 

M I* — 

84 * CHECK STATUS DAEMON CLASS 

§1 * */ 

hue 

83 class CheckStatusThread implements Runnable { 

84 private HostAgent agent; 

85 CheckStatusThread(HostAgent ha) { 

86 agent = ha; 

87 } 

88 public void run() { 

89 System.out.println("Starting check status thread"); 

90 // HostAgent.checkThreads(agent); 

9 1 HostAgent. checkProcs(agent); 
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92 } 

93 } 



94 /* 

95 * HOST AGENT CLASS 

96 * 

97 * The host agent class will keep alive all jobs that it starts. 

98 * Started jobs are assumed to want to run forever — there is no 

99 * "normal" exit state, so all started jobs are kept alive until 

1 00 * kill Job is called in this version. 

101 * */ 

102 class HostAgent extends UnicastRemoteObject implements HostAgent_Interface { 

1 (Is private Runtime runtime; 

1(|| private String HostName; 

idS private String ProcessID; 

1 6q private final int MAX_WAIT_SECONDS = 60; 

m% private final String COORD_PROGRAM = "/bin/coordinator"; 

l(j&^ // private Coordinator coordinator; 

10© private Process CobrdProcess; // only set if Coordinator runs locally 

1 W private Process FrontEndProcess; // only set if FrontEnd runs locally 

ifji 

1 Ip^^ /** HostAgent constructor - 

1 ri * Called during system boot process or by Coordinator after HostAgent 

114 * crash. 

115 */ 

1 1 6 public HostAgent(String hostname) throws java.rmi.RemoteException { 

117 superQ; 

1 18 ProcessID = new String ("processID"); // XXX get process id 

119 runtime = Runtime.getRuntimeO; 

1 20 HostName = hostname; 

121 // if (findCoordinatorO = false) { 

1 22 //startCoordinatorQ; 

123 // } 

124 } 
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/** pingHostAgent ~ 

* essentially a ping for the HostAgent process. 
*/ 

public boolean pingHostAgentQ throws java.rmi.RemoteException { 
return true; 

} 



private void startProcess(String jobName, String cmd) { 
Process proc; 



try{ 




// 


System.out.println("startProcess: starting " + cmd); 


proc 


= runtime.exec(cmd); 


// 


System.out.println("startProcess: reading output"); 


// 


byte[] data = new byte[256]; 


// 


proc.getlnputStreamQ.read (data); 


// 


System.out. write (data); 



JobList.addJob(jobName, cmd, proc); 

} 

catch (java.io.IOException err) { 

System.err.println("HostAgent.startJob exec failed"); 
System.err.println(err,getMessageO); 

} 

} 



private void startThread(String jobName, String cmd) { 
Thread t = new Thread (new JobThread(cmd)); 
t.startO; 

JobList.addJob(jobName, cmd, t); 



public void startJob(String jobName, String cmd) { 
startProcess(jobName, cmd); 
// startThread(jobName, cmd); 

} 
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158 

159 public void killJob(String jobName) throws java.rmi.RemoteException { 

160 try{ 

1 6 1 Object obj = JobList.removeJob(jobName); 

162 if (obj.getClassQ = Thread.class) { 

1 63 Thread t = (Thread) obj ; 

164 t.destroyO; 

165 if (t.isAliveO) { 

166 HaraKiriO; 

167 } 

168 } 

169 if (obj.getClassQ = Process.class) { 
17Q Process proc = (Process) obj; 

1 proc.destroyO; 

m try{ 

1 W proc.exitValueO; 

17# } 

1 7g catch (lUegalThreadStateException err) { 

life HaraKiriO; 

nf } 

m } 

ifl } 

1 m catch (NoSuchJob err) { 

1 8:t // Don't need to do anything here, 

Ig } 

1 84 // Used to convert potential falures into full failures and to commit suicide v^hen 

185 // multiple instances are started. This is usually done in instances of the 

1 86 // coordination of higher level matters. 

187 public void HaraKiri() { 

1 88 System.out.println("HostAgent commiting Hara Kiri"); 

189 System.exit(l); 

190 } 

191 /* */ 

192 static void checkThreads(HostAgent agent) { 
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193 int sleepTime = 1000; // in milliseconds 

1 94 JobListReport [] j oblist; 

195 Thread t; 

196 boolean alive; 

197 while (true) { 

198 try { 

199 Thread.sleep(sleepTime); 

200 } 

201 catch (java.lang.InterruptedException exp) { 

202 System.err.println("Thread interrupted"); 

203 } 

2(^ j oblist = JobList.getJobListO; 

2q1 for (int i=0; i < joblist.length; { 

2m t = (Thread) joblist[i] .object; 

20p alive = t.isAliveO; 

'•■ti 

20i // System.out.println("Job " + j oblist [i].jobName + " isAlive: " + alive); 
2^ 

2fQ if(alive== false) { 

2tTj try { 

2^1 System.out.println("Restarting " + joblist[i].jobName); 

2La Object obj = JobList.removeJob(joblist[i].jobName); 

2rt agent.startJob(joblist[i].jobNameJoblist[i].coinmand); 

2i } 

216 catch (NoSuchJob err) { 

217 // if we get here, the job has been removed between 

218 // the getJobList and remove Job. Since it should 

219 // only be removed here or by specifically calling 

220 // killJob, a killJob must have been called, so 

22 1 // we don't want to restart this job. 

222 } 

223 } 

224 } 

225 

226 } 
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228 static void checkProcs(HostAgent agent) { 

229 int sleepTime = 1000; // in milliseconds 

230 JobListReport [] joblist; 

23 1 Process proc; 

232 boolean alive; 

233 while (true) { 

234 try { 

235 Thread.sleep(sleepTime); 

} 

2S% catch (java.lang.InterruptedException exp) { 

2^S System.err.println("Thread interrupted"); 

m } 



24(1 joblist = JobList.getJobListO; 

241 for (int i=0; i < joblist.length; i-H-) { 

24? proc = (Process) joblist[i].object; 

24^! alive = false; 

24| try { 

245 proc.exitValueQ; 

246 } 

247 catch (IllegalThreadStateException err) { 

248 alive = true; 

249 } 

250 // System.out.println("Job " + joblist[i].jobName + " isAlive: " + alive); 

251 if (alive) { 

252 try { 

253 byte[] data = new byte[256]; 

254 proc.getlnputStreamO.read (data); 

255 System.out. write (data); 

256 } 

257 catch (lOException err) { 

258 System.err.println("IO Error"); 

259 System.err.println(err.getMessageO); 
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260 } 

261 } 
262 

263 else { 

264 try { 

265 System.out.println("Restarting " + joblist[i] jobName); 

266 Object obj = JobList.removeJobGobiist[i].jobName); 

267 agent.startJob(joblist[i].jobNameJoblist[i]. command); 

268 } 

269 catch (NoSuchJob err) { 

270 // if we get here, the job has been removed between 

271 // the getJobList and remove Job. Since it should 

272 // only be removed here or by specifically calling 

273 // killJob, a killJob must have been called, so 

274 // we don*t want to restart this job. 

Tfi } 

2iK } 
m } 

27& 

273 } 

2m } 

2S1 // Additional methods not used during demonstration mode are commented out here. 

2^ /** checkStatuS" 

2^ * Periodically called to check: 

28S * 1) whether a Coordinator is rurming locally 

2^ * 2) whether a FrontEnd is rurming locally 

2fS^ * 3) status for each process in jobUst 

287 * 4) overall system load 

288 * Currently system load is represented by the number of jobs. 

289 */ 

290 // private HostAgentReport checkThreadStatusQ { 

291 // HostAgentReport report = new HostAgentReport(joblist.length); 

292 // Set jobNameSet = joblist.keySetQ; 

293 // Iterator i = jobNameSet,iterator(); 

294 // int count; 

295 // Process proc; 

296 // Thread t; 

297 // report.jobNames = new String [joblist. length]; 
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298 // for (count = 0; count < joblist.length; count-H-) { 

299 // report.jobNames[i] = i.nextQ; 

300 // proc = report.jobNames[i].getProcessO; 

301 // } 

302 // // do not restart if problem, just set values to null 

303 // report.localCoordinator = (CoordProcess != null); 

304 // report. localFrontEnd = (FrontEndProcess != null); 

305 // report.systemLoad.jobqueue= joblist.length; 

306 // return report; 

307 // } 

3di II /** getHostList" 

3(|^ // */ 

3|j^ // private String [] getHostListQ { 

3U! // String allHostNames = {"cbo", '*nyse", "nasdaq", "pse"}; 

3 r!i // return allHostNames; 

3t? // } 

3 ft // /** findCoordinator -- 

3L5| II * Query all known hosts for Coordinator process. 

Sll // */ 

3 lf7i // private boolean findCoordinatorQ { 

3l|| // String allHosts [] = makeAUHostListO; 

319" // Remote robj; 

320 // boolean foundCoordinator — false; 

321 // for (int i = 0; i < allHosts.length; 1++) { 

322 // if (foundCoordinator == false) { 

323 // try{ ^ 

324 // robj - Naming.lookup(7/" + allHosts[i] + "/Coordi- 

325 nator"); 

326 // coordinator = (Coordinator) robj; 

327 // foundCoordinator = coordinator.getCoordinatorQ; 

328 // } 

329 // } 

330 // } 
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331 // 

332 // 

333 
334 
335 
336 
337 

338 // 

339 // 

340 // 

341 // 

342 // 

343 // 
3€4 // 
3i5 II 
IM II 
34^ // 
34i // 
3|9 // 
356 // 
3|l // 

m II 

3S| // 

3si // 

m II 

3Sg // 



357 // 

358 // 

359 // 

360 // 

361 // 

362 // 

363 // 

364 // 



/** startCoordinator — 

* 1) Wait in case another host is starting a coordinator. 

* 2) Check again for Coordinator. 

* 3) If none exists, start one on local host. 



private void startCoordinatorQ { 

InetAddress InetAddr = InetAddress.getByName("localhost"); 



int rand - (InetAddr + ProcessID) % MAX_WAIT_SECONDS; 

Thread t = Thread.currentThreadO; 
try( 

t.sleep(rand); 

} 

catch (InterrupedException ie) { 

} 

if (findCoordinatorO) { 
return; 



coordProcess = runtime.exec(COORD_PROGRAM); 



} 

} 



/**jobExit 

* Called by exiting processes started by this HostAgent. 

* Remove job fromjoblist. 
*/ 

public void jobExit(String jobName) { 

Process proc = joblist.getProcess(jobName); 
joblist.removeJob(jobName); 
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365 


II 


public void reportStatusQ { 


366 


II 


HostAgentReport report = checkStatusQ; 


367 


II 


try{ 


368 


II 


coordinator.reportStatus(report); 


369 


II 


} 


370 


II 


catch (RemoteException err) { 


371 


II 


startCoordinatorQ; 




II 


} 


373 


II 


} 


374 


• •• 




3W 


// In this example code, some jobs are started and kept alive, even over 'kill-9' com- 


3W 


mands. 








public static void main (String[] args) { 


31% 




HostAgent hostAgent; 




String hostname = null; 


38„0 




String port = null; 


n 

38i 




if (args.length != 2) { 


382- 




System.err.println("usage: hostname port"); 


3sii 




return; 






} 


381 




hostname = args[0]; 


386 




port = args[l]; 


387 




System.setSecurityManager (new RMISecurityManagerQ); 


388 




try{ 


389 




hostAgent = new HostAgent(hostname); 


390 




Naming.rebind ("//" + hostname + ":" + port + "/HostAgent", hostAgent); 


391 




} 


392 




catch (Exception e) { 


393 




System.err.println(*Tailed to register HostAgent"); 


394 




System.out.println(e.getMessageO); 


395 




e.printStackTraceO; 
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396 return; 

397 } 

398 System.out.printlnC'HostAgent started on " + hostAgent.HostName); 

399 // start checkStatus daemon 

400 Thread t = new Thread (new CheckStatusThread(hostAgent)); 

401 t.startO; 

402 hostAgent.startJobC'vecn", "/bin/java -Xms 1 00m -Xmx200m 

403 MEC.NodeControUer.NodeControUer IBM INKT MSFT YHOO QCOM WCOM INTC DELL 

404 ORCL AMZN CSCO GSTRF"); 

405 // hostAgent.startJob("demoA", "/bin/java DemoAppA"); 

406 // hostAgent.startJob("demoB", "/bin/java DemoAppB"); 
4Q=7, // hostAgent.startJob("demoA", "DemoAppA"); 

4Q| // hostAgent.startJob("demoB", "DemoAppB"); 

4m } 

4m } 



rlj 
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While the invention has been particixlarly shown and described with reference to one em- 
bodiments thereof it will be understood by those skilled in the art that various changes in form 
and details may be made therein without departing from the scope of the invention. 



Attorney Docket No.: ATAE1015DEL Express Mail Label No.:EL328296286US 

ioi5_oo^7^20.fi.wpd Page 78 of 94 7/20/0-22:31 



